Vorteile der Verwendung von VMware VAAI auf der Hitachi Unified Storage 100-Produktfamilie

Transkript

1 Vorteile der Verwendung von VMware VAAI auf der Hitachi Unified Storage 100-Produktfamilie Labortestbericht Von Erico Cardelli, Chris Didato 23. August 2012

2 Feedback Hitachi Data Systems freut sich über Ihr Feedback. Anregungen nehmen wir gerne per an entgegen. Nennen Sie für die bessere Übermittlung dieser Nachricht die Dokumentnummer im Betreff und den Titel dieses Whitepaper im Text.

3 Inhalt Produktfunktionen...3 Hitachi Unified Storage Hitachi Dynamic Provisioning...4 Hitachi Compute Blade VMware vsphere VMware vstorage APIs for Array Integration (VAAI)...5 Testumgebung...7 Testmethodik...11 Klonen mit vollständiger Kopie...12 Festplattenauslastung bei Blockeliminierung mit Hitachi Dynamic Provisioning.13 Performance der Blockeliminierung beim Aufwärmen...15 Blockeliminierung mit Zero Page Reclaim...16 Großflächiger Boot Storm mit hardwaregestützter Sperrung...18 Großflächiges simultanes vmotion mit hardwaregestützter Sperrung...19 Thin Provisioning Stun...20 Analyse...22 Klonen mit vollständiger Kopie...22 Festplattenauslastung bei Blockeliminierung mit Hitachi Dynamic Provisioning.22 Großflächiger Boot Storm mit hardwaregestützter Sperrung...23 Großflächiges simultanes vmotion mit hardwaregestützter Sperrung...23 Thin Provisioning Stun...24 Vollständige Testergebnisse...25 Klonen mit vollständiger Kopie...25 Festplattenauslastung bei Blockeliminierung mit Hitachi Dynamic Provisioning.29 Performance der Blockeliminierung beim Aufwärmen...30 Blockeliminierung mit Zero Page Reclaim...33 Großflächiger Boot Storm mit hardwaregestützter Sperrung...34 Großflächiger Boot Storm mit hardwaregestützter Sperrung...36 Thin Provisioning Stun...37 Zusätzliche Informationen über VMware vstorage APIs for Array Integration...38 Vollständige Kopie...38 Blockeliminierung...39 Hardwaregestützte Sperrung...40 Thin Provisioning Stun...42

4 1 1 Vorteile der Verwendung von VMware VAAI auf der Hitachi Unified Storage 100-Produktfamilie Labortestbericht Dies sind die Vorteile der Verbindung von Hitachi Unified Storage mit vstorage APIs for Array Integration (VAAI) auf ESX 5.0 von VMware. Dieser Test unterstützt die folgenden Empfehlungen. Implementieren Sie bei Bedarf einer maximalen Ausgangsleistung die folgenden Einstellungen: Verwenden Sie eine virtuelle Festplatte im eagerzeroedthick-format, um Leistungsstörungen zu vermeiden. Konfigurieren Sie Hitachi Unified Storage und Hitachi Dynamic Provisioning zur nativen Unterstützung von Thin Provisioning ohne den durch die Verarbeitung von Thin Provisioning auf der Virtualisierungsschicht und der Speichersystemschicht verursachten doppelten Overhead. Aktivieren Sie VAAI auf allen Hosts, um die Hitachi Unified Storage- Unterstützung der vstorage APIs wahrnehmen zu können. Implementieren Sie bei Bedarf einer maximalen Kosteneinsparung und ni0 edrigem administrativen Overhead die folgenden Einstellungen: Verwenden Sie virtuelle Festplatten im Thin- oder lazyzeroedthick- Format. Konfigurieren Sie Hitachi Dynamic Provisioning-Volumes. Aktivieren Sie VAAI auf allen Hosts, um die Hitachi Unified Storage- Unterstützung der vstorage APIs wahrnehmen zu können. Aktivieren Sie die hardwaregestützten Sperrfunktionen. Führen Sie für Volumes regelmäßig das Zero Page Reclaim- Dienstprogramm auf Hitachi Dynamic Provisioning aus.

5 2 2 Dieses Dokument wendet sich an Speicheradministratoren, vsphere-administratoren, Anwendungsadministratoren oder Architekten für Virtualisierungsinfrastruktur, die für die Verwaltung großer, dynamischer VMware-basierter virtueller Umgebungen zuständig sind. Sie benötigen Kenntnisse über SAN-basierte Speichersysteme, VMware vsphere und allgemeine IT-Speichermethoden. Hinweis Der Test wurde in einer Laborumgebung durchgeführt. Produktionsumgebungen werden von vielen Faktoren beeinflusst, die sich in einer Laborumgebung nicht vorhersehen oder simulieren lassen. Es wird empfohlen, vor der Implementierung dieser Lösung in Ihrer Produktionsumgebung Proof-of-Concept-Tests durchzuführen, um akzeptable Ergebnisse zu erzielen. Das bedeutet, dass Anwendungen in einer nicht für die Produktion bestimmten, isolierten Testumgebung geprüft werden, die ansonsten Ihrer Produktionsumgebung entspricht.

6 3 3 Produktfunktionen Dies sind die Funktionen einiger in der Testphase verwendeter Produkte. Hitachi Unified Storage 150 Hitachi Unified Storage ist eine Midrange-Speicherplattform für alle Daten. Sie unterstützt Unternehmen bei der Erfüllung von Service-Level-Agreements in den Bereichen Verfügbarkeit, Performance und Datensicherheit. Die von Hitachi Unified Storage bereitgestellte Performance ist zuverlässig, skalierbar und für Block- und File-Daten verfügbar. Unified Storage verfügt über einfaches Management, ist für kritische Unternehmensanwendungen optimiert und arbeitet effizient. Unified Storage ist mit geringeren Anschaffungskosten verbunden. Der Speicher wächst mit den Anforderungen und Service-Level-Agreements und ist für die Bereitstellung von kritischen Unternehmensanwendungen gedacht. Integriertes Setup und Management vereinfachen den Betrieb und beschleunigen die Wertschöpfung. Unified Storage ermöglicht erhebliche Kosteneinsparungen durch die Konsolidierung von File- und Blockdaten. Erstellen Sie abhängig vom Bedarf eine Cloud zur Bereitstellung Ihrer Services. Hitachi Unified Storage 150 bietet flexiblen, skalierbaren und kosteneffektiven modularen Speicher. Die symmetrischen Active/Active-Controller bieten einen integrierten, automatischen und hardwarebasierten E/A-Lastausgleich. Beide Controller in Unified Storage 150 weisen die Zugriffspfade von Controller zu logischer Einheit (LU) automatisch und dynamisch zu. Es besteht Zugriff auf alle LUs, ganz gleich, um welchen physischen Port es sich handelt oder welcher Server Zugriff anfordert. Aufgrund der engen Integration ist Hitachi Unified Storage mit VMware vsphere 5.0-Implementierungen der VAAI-APIs kompatibel. Die native Unterstützung verbessert die folgenden Funktionen: Storage vmotion Klonen Provisionierung virtueller Computer SCSI-Reservierungssperren, wodurch die SAN-Leistung für virtualisierte Umgebungen optimiert wird. Verwendung von nativem Thin-Speicher und Hochleistungs-Datenverwaltung durch Hitachi Unified Storage. Dadurch ergibt sich die Option, Thick-Speicher auf der Virtualisierungsschicht zu verwenden, während die Speicherschicht Thin Provisioning verwendet. Dabei fällt kein zusätzlicher Overhead an.

7 4 4 Hitachi Dynamic Provisioning Auf Hitachi-Speichersystemen verfügt Hitachi Dynamic Provisioning über Wide Striping- und Thin Provisioning-Funktionen. Die Verwendung von Dynamic Provisioning gleicht einem hostbasierten logischen Volume-Manager (LVM), allerdings ohne den anfallenden Verarbeitungs- Overhead. Dynamic Provisioning bietet einen oder mehrere Wide-Striping-Pools über viele RAID-Gruppen hinweg. Für jeden Pool werden ein oder mehrere Dynamic Provisioning Virtual Volumes (DP-VOLs) mit einer von Ihnen festgelegten logischen Größe von bis zu 60 TB erstellt, ohne dass vorher physischer Speicherplatz zugewiesen werden muss. Durch die Bereitstellung von Dynamic Provisioning werden die typischen Probleme im Zusammenhang mit besonders stark beanspruchten Bereichen, sogenannten Hotspots, auf logischen Speichergeräten (LDEVs) vermieden. Diese sind innerhalb einzelner RAID-Gruppen anzutreffen, sobald die Workload des Hosts die IOPS- oder Durchsatzkapazität der RAID-Gruppe überschreitet. Mit Dynamic Provisioning wird die Workload des Hosts über mehrere RAID- Gruppen verteilt, wodurch die Prozesse reibungsloser vonstatten gehen und Hotspots vermieden werden können. In Verbindung mit Hitachi Unified Storage bietet Hitachi Dynamic Provisioning den Vorteil von Thin Provisioning. Die Zuweisung des physischen Speichers aus dem Pool an das Dynamic Provisioning Volume erfolgt nach Bedarf in 1-GB-Schritten, bis die für jedes Dynamic Provisioning Volume festgelegte logische Größe erreicht ist. Die Kapazität des Pools kann ohne Unterbrechung oder Ausfallzeit dynamisch erweitert oder verkleinert werden. Ein erweiterter Pool kann für ein gleichmäßiges Striping von Daten und Workload über aktuelle und neu hinzugefügte RAID-Gruppen hinweg neu angepasst werden. Hitachi Compute Blade 2000 Hitachi Compute Blade 2000 ist eine Bladeserverplattform der Enterprise-Klasse. Sie bietet die folgenden Features: Eine ausgewogene Systemarchitektur, die keine Engpässe bei Performance und Durchsatz zulässt Flexibilität bei der Konfiguration Umweltfreundliche Energiesparfunktionen Schnelle Wiederherstellung bei Serverausfällen mithilfe einer N+1 Cold Standby-Ausführung zum Austausch von ausgefallen Servern innerhalb weniger Minuten

8 5 5 VMware vsphere 5 VMware vsphere 5 ist eine Virtualisierungsplattform, die eine Rechenzentrumsinfrastruktur bietet. Die Funktionen umfassen vsphere Distributed Resource Scheduler (DRS), hohe Verfügbarkeit und Fehlertoleranz. VMware vsphere 5 verfügt über die folgenden Komponenten: ESXi 5.0 Ein Hypervisor, der direkt auf einem physischen Server geladen wird. Hiermit wird eine physische Maschine in viele virtuelle Maschinen partitioniert, die gemeinsame Hardware-Ressourcen verwenden. vcenter Server Ermöglicht das Management der vsphere-umgebung über eine einzige Benutzeroberfläche. vcenter verfügt unter anderem über Funktionen wie vmotion, Storage vmotion, Storage Distributed Resource Scheduler, hohe Verfügbarkeit und Fehlertoleranz. VMware vstorage APIs for Array Integration (VAAI) Mit VMware vstorage APIs for Array Integration (VAAI), auch bekannt als Stammfunktionen, können vsphere-umgebungen erweiterte Funktionen von Hitachi Unified Storage verwenden. Die Benutzung von vstorage APIs bietet eine Möglichkeit, die erweiterten Speicherfunktionen von Hitachi Unified Storage von innerhalb der VMware-Oberfläche aus zu nutzen. Die Verarbeitung findet direkt auf der Speicherinfrastruktur statt. Diese Leistungsverbesserungen verschieben die E/A-Workload von der abhängigen vcenter-hostplattform in den Speichercontroller. Anstatt die Verarbeitung durch den Verbrauch von Rechenleistung, Speicher und Bandbreite zu verlangsamen, beschleunigen diese Vorgänge den Betrieb, verschieben potenzielle Engpässe durch eingeschränkte Ressourcen und machen das Virtualisierungsmanagement für wichtigere Aufgaben verfügbar. Bei Verwendung mit vsphere 5.x unterstützt Hitachi Unified Storage die folgenden API-Stammfunktionen: Vollständige Kopie Diese Stammfunktion lässt das Speichersystem volle Datenkopien innerhalb des Speichersystems erstellen, ohne dass der ESX-Host die Daten lesen und schreiben muss. Blockeliminierung Diese Stammfunktion lässt Speichersysteme eine große Menge Blöcke durch Nullbytes ersetzen, um die Provisionierung virtueller Maschinen zu beschleunigen. Hardwareunterstützte Sperrung Diese Stammfunktion bietet eine alternative Methode, die VMFS-Metadaten von Cluster-File-Systemen zu schützen, wodurch die Skalierbarkeit großer ESX-Hostfarmen, die einen gemeinsamen Datenspeicher verwenden, verbessert wird.

9 6 6 Thin Provisioning Stun Diese Stammfunktion sorgt dafür, dass das Speichersystem den ESX-Host informiert, wenn Thin Provisioninggestützte Volumes einen bestimmten Schwellenwert der Kapazitätsauslastung erreichen. Bei Aktivierung kann der ESX-Host dadurch vorbeugende Maßnahmen ergreifen, um die Integrität der virtuellen Maschine zu wahren. Siehe Zusätzliche Informationen über VMware vstorage APIs for Array Integration auf Seite 38 für weitere Informationen.

10 7 7 Testumgebung Es folgt eine Beschreibung der im Labor von Hitachi Data Systems verwendeten Testumgebung. Abbildung 1 zeigt das physische Layout der Testumgebung. Abbildung 1

11 8 8 Abbildung 2 zeigt die virtuellen Maschinen, die mit dem auf Hitachi Compute Blade 2000 gehosteten VMware vsphere 5-Cluster verwendet werden. Abbildung 2

12 9 9 Tabelle 1 zeigt die in diesem Labortestbericht verwendeten Hitachi Compute Blade und Speicherkomponenten. Tabelle 1. Hitachi Compute Blade und Speicherkonfiguration Hardware Beschreibung Version Hitachi Compute Blade Chassis mit 8 Serverblades A0195-C-6443 Chassis 4 Netzwerk-Switchmodule mit 1/10 Gbit/s 2 Management-Module 8 Lüftermodule 4 Netzteilmodule 8 8-Gbit/s-Fibre-Channel-PCI-e-HBA-Ports Hitachi E55A2-Serverblade 2 Intel Xeon E5503 Dual-Core- Prozessoren mit 2 GHz GB RAM pro Blade 4 Blades im Chassis Hitachi Unified Storage GB Cache 0915/B-H 4 Fibre-Channel-Ports mit 8 Gbit/s Mehrere SAS-Festplattenkonfigurationen mit 600 GB und U/min Tabelle 2 führt die in diesem Labortestbericht verwendete VMware vsphere 5-Software auf. Tabelle 2. VMware vsphere 5-Software Software Version VMware vcenter Server Build VMware vsphere Client Build VMware ESXi Build Alle in diesem Labortestbericht erwähnten virtuellen Maschinen verwendeten die Enterprise-Edition von Microsoft Windows Server 2008 R2 64-Bit als Betriebssystem.

13 10 10 Tabelle 3 zeigt die in diesem Labortestbericht überprüften virtuellen Festplattenformate von VMware vsphere 5. Tabelle 3. Virtuelle Festplattenformate von VMware vsphere 5 Virtuelle Festplattentypen Thin Lazyzeroedthick Eagerzeroedthick Beschreibung Der virtuellen Festplatte wird nur die Speicherkapazität zugewiesen, die vom Gastbetriebssystem benötigt wird. Bei Schreibvorgängen wird zusätzlicher Speicherplatz zugewiesen und durch Nullbytes ersetzt. Die virtuelle Festplatte nimmt die maximal verfügbare Größe an. Die Speicherkapazität der virtuellen Festplatte wird bei der Erstellung zugewiesen. Die virtuelle Festplatte nimmt nicht an Größe zu. Der zugewiesene Speicherplatz wird jedoch nicht vorher durch Nullbytes ersetzt. Wenn das Gastbetriebssystem auf die virtuelle Festplatte schreibt, wird der Speicherplatz nach Bedarf durch Nullbytes ersetzt. Die Speicherkapazität der virtuellen Festplatte wird bei der Erstellung zugeteilt. Die virtuelle Festplatte nimmt nicht an Größe zu. Die virtuelle Festplatte ist mit Nullbytes beschrieben. Wenn das Gastbetriebssystem auf die virtuelle Festplatte schreibt, muss der Speicherplatz nicht durch Nullbytes ersetzt werden.

14 11 11 Testmethodik Zeit- und Leistungskennzahlen wurden in jedem Testfall mehreren Quellen entnommen. Alle Verwaltungsfunktionen von Hitachi Unified Storage wurden mit der Hitachi Storage Navigator Modular 2-Software durchgeführt. Alle VMware vsphere 5-Vorgänge wurden mit dem vcenter- und vsphere- Client durchgeführt. Für die Synchronisierung der Ergebnisse wurden Daten der folgenden Standorte erfasst: Hitachi Unified Storage Hitachi Storage Navigator Modular 2 Grafische Benutzeroberfläche Befehlszeilenschnittstelle VMware ESX-Host Durch ESXTOP wurden die Messdaten der virtuellen Hosts erfasst vcenter Server Über den vsphere-client verbunden Virtuelle Maschinen VDBench Workload und Protokolle wurden direkt aus den virtuellen Maschinen generiert Dies sind die Beschreibungen der Testfälle: Klonen mit vollständiger Kopie auf Seite 12 Festplattenauslastung bei Blockeliminierung mit Hitachi Dynamic Provisioning auf Seite 13 Performance der Blockeliminierung beim Aufwärmen auf Seite 15 Blockeliminierung mit Zero Page Reclaim auf Seite 16 Großflächiger Boot Storm mit hardwaregestützter Sperrung auf Seite 18 Thin Provisioning Stun auf Seite 20

15 12 12 Klonen mit vollständiger Kopie Das Ziel dieser Testphase war der Vergleich der Systemleistung mit der Auslagerung des Klonverfahrens virtueller Maschinen zu Hitachi Unified Storage mithilfe der aktivierten Stammfunktion für vollständige Kopien und der deaktivierten Auslagerung des Klonverfahrens. Das Testverfahren beinhaltete das Klonen der folgenden VMDKs von einem Quelldatenspeicher (RAID-6-source) aus einem Dynamic Provisioning-Pool in einen Zieldatenspeicher in einem anderen Dynamic Provisioning-Pool (RAID-6-target): Lazyzeroedthick-VMDK mit 30 GB Thin-VMDK mit 30 GB Eagerzeroedthick-VMDK mit 30 GB Tabelle 4 zeigt die Testfälle. Tabelle 4. Testfälle für das Klonen mit vollständiger Kopie Fall Datenformat der virtuellen Festplatte 1 Virtuelle Festplatten im Thin-Format mit 30 GB 2 Virtuelle Festplatten im lazyzeroedthick-format mit 30 GB 3 Virtuelle Festplatten im eagerzeroedthick-format mit 30 GB Bei allen drei Testfällen wurde der folgende Prozess durchgeführt: 1. Erstellen eines Dynamic Provisioning-Pools mit einer einzigen RAID-6- Gruppe (6D+2P) mit SAS-Festplatten (600 GB, U/min), um einen VMFS-Datenspeicher mit der Bezeichnung RAID-6-source (HDP-0) zu erstellen. 2. Erstellen einer virtuellen Maschine mit Microsoft Windows Server 2008 R2 und einer virtuellen Festplatte im Thin-Provisioning-Format auf RAID-6- source (HDP-0). 3. Konvertieren der virtuellen Windows-Maschine in eine Vorlage. 4. Erstellen eines zweiten Dynamic Provisioning-Pools mit einer RAID-6-Gruppe (6D+2P) als VMFS-Datenspeicher mit der Bezeichnung RAID-6-target (HDP-1) unter der Verwendung von SAS-Festplatten mit 600 GB und U/min. 5. Für einen der Testfälle: Provisionierung einer virtuellen Maschine in jedem virtuellen Datenträgerformat aus einer Vorlage auf dem Datenspeicher RAID-6-source (HDP-0) zu einem Zieldatenspeicher RAID-6-target (HDP-1). 6. Provisionierung aller virtuellen Maschinen bei aktivierter und deaktivierter Stammfunktion für vollständige Kopien.

16 13 13 Abbildung 3 zeigt das Speicherlayout. Abbildung 3 Festplattenauslastung bei Blockeliminierung mit Hitachi Dynamic Provisioning Das Ziel dieser Testphase war die Demonstration der Auswirkungen der Stammfunktion für die Blockeliminierung. Das Testverfahren beinhaltete die Provisionierung virtueller Festplatten, die in einer LU auf Hitachi Dynamic Provisioning-Pools bei aktiviertem und deaktiviertem VAAI innerhalb eines frischen und eines verschmutzten Datenspeichers konfiguriert wurden. Ein frischer Datenspeicher ist ein neu formatierter unbenutzter Datenspeicher. Ein verschmutzter Datenspeicher ist ein Datenspeicher, auf dem ohne die Stammfunktion für die Blockeliminierung oder Zero Page Reclaim- Optionen VMDK-Dateien erstellt und gelöscht wurden. Abbildung 4 zeigt den Standort und die Einstellung der Stammfunktion für die Blockeliminierung innerhalb der erweiterten Einstellungen des ESX-Hosts. Abbildung 4

17 14 14 Bereitstellung eines frischen Dynamic Provisioning-Volumes Messen Sie bei aktiviertem und deaktiviertem VAAI mithilfe einer 30 GB großen eagerzeroedthick-vmdk-datei auf einem frischen Dynamic Provisioning-Volume den tatsächlichen verbrauchten Speicherplatz auf dem Speichersystem und die für den Prozess benötigte Zeit. Der Test beginnt mit einem frischen Dynamic Provisioning-Pool. 1. Stellen Sie den gewünschten Wert für die VAAI-Stammfunktion ein. 2. Führen Sie ESXTOP durch, um alle Daten zu erfassen. 3. Stellen Sie eine virtuelle Maschine auf einer 30 GB großen eagerzeroedthick- VMDK bereit. 4. Messen Sie den verbrauchten Speicherplatz auf dem Hitachi Dynamic Provisioning-Pool. Bereitstellung eines zu 100 % verschmutzten Dynamic Provisioning-Volumes Verwenden Sie eine VMDK-Datei im eagerzeroedthick-format mit 30 GB, die auf einem Dynamic Provisioning-Volume erstellt wurde und mit Daten gefüllt ist. Löschen Sie die VMDK. Dadurch wird ein verschmutztes Dynamic Provisioning- Volume erstellt, bei dem 100 % der im Volume befindlichen Seiten zugewiesen bleiben. Verwenden Sie dann das verschmutzte Volume, um eine neue VMDK zu erstellen. Messen Sie bei aktiviertem VAAI den tatsächlich verbrauchten Speicherplatz auf dem Speichersystem auf einem Dynamic Provisioning-Volume und die für den Prozess benötigte Zeit. Der Test beginnt mit einer zu 100 % verschmutzten Dynamic Provisioning- Volume. 1. Aktivieren Sie die VAAI-Stammfunktion. 2. Stellen Sie eine VMDK im eagerzeroedthick-format mit 30 GB bereit. 3. Messen Sie den verbrauchten Speicherplatz der Festplatte auf dem Dynamic Provisioning-Pool. 4. Legen Sie die grundlegende Speichernutzung fest. 5. Versichern Sie sich, dass VAAI für Zero Page Reclaim aktiviert ist. 6. Führen Sie Zero Page Reclaim für die LU durch. 7. Messen Sie den verbrauchten Speicherplatz auf dem Dynamic Provisioning-Pool.

18 15 15 Performance der Blockeliminierung beim Aufwärmen Das Ziel dieses Tests war die Untersuchung der Verwendung der Stammfunktion für Blockeliminierung für das Erstellen einer neuen VMDK-Festplatte auf bestehenden SAN- oder Blockpräsentationen. Nach dem Erstellen der VMDK hängt die Zugriffsart von ihrem Format ab. Bis die Festplatte vollständig durch Nullbytes ersetzt ist, kommt es zu Leistungsschwankungen. Das Aufwärmen einer Festplatte bedeutet ihre vollständige Überschreibung mit Nullbytes. Dieser Test untersuchte die Aufwärmfolgen der verschiedenen Formate: Thin, lazyzeroedthick und eagerzeroedthick. Die Tests wurden mit der VAAI- Stammfunktion bei aktivierter und deaktivierter Blockeliminierung auf Hitachi Dynamic Provisioning-Pools durchgeführt. Beim Bewertungsprozess wurde eine VMDK-Datei in einem neuen (sauberen) Dynamic Provisioning-Pool erstellt und eine 100 %-Schreibbelastung von 1000 IOPS aus einer virtuellen Maschine erzeugt, die diese VMDK-Datei verwendet. Tabelle 5 führt die verschiedenen Testfälle auf, die für die Aufwärmtests verwendet wurden. Tabelle 5. Aufwärmtestfälle Fall Einstellung der VAAI- VMDK-Format Stammfunktion 1 Aktiviert Eagerzeroedthick mit 100 GB 2 Aus Eagerzeroedthick mit 100 GB 3 Aktiviert Thin mit 100 GB 4 Aus Thin mit 100 GB 5 Aktiviert Lazyzeroedthick mit 100 GB 6 Aus Lazyzeroedthick mit 100 GB Der Test beginnt mit einer frischen Dynamic Provisioning-Volume für jeden Testfall. 1. Legen Sie die VAAI-Stammfunktion fest. 2. Provisionieren Sie die VMDK. 3. Laden Sie die virtuelle Maschine mit E/A von VDBench. 4. Legen Sie die Baseline für das Aufwärmen des Speichers fest.

19 16 16 Abbildung 5 zeigt die verwendete Speicherkonfiguration. Abbildung 5 Blockeliminierung mit Zero Page Reclaim Das Ziel dieses Tests war die Demonstration der Optimierung eines Dynamic Provisioning-Volumes durch die Ausführung von Zero Page Reclaim und der Stammfunktion für Blockeliminierung. Zero Page Reclaim nutzt die Virtualisierung von Hitachi Dynamic Provisioning-Pools, um Thick -Daten zu verschieben und dadurch das Entfernen von Speicherseiten zu ermöglichen, die leer sind (oder voller Nullbytes). Dies reduziert die tatsächliche Zuweisung von Speicher, um Zuweisungen für Thin-Speicher auf der LU zu erstellen. Dieser Test begann mit deaktiviertem VAAI auf einer mit lazyzeroedthick provisionierten virtuellen Maschine, einer 100-GB-Festplatte und 8 GB verbrauchten Daten. Der Platzverbrauch wird auf der LU vom Speichersystem aus gemessen. Daraufhin wird die VMDK in eine eagerzeroedthick-vmdk konvertiert, um zu überprüfen, dass der Speicherplatz durch Nullbytes ersetzt wird. Nach der Provisionierung wurde Zero Page Reclaim auf der LU durchgeführt, um den Platzverbrauch zu kontrollieren. Tabelle 6 zeigt diese Testfälle. Tabelle 6. Zero Page Reclaim-Testfälle Fall VAAI 1 An 2 Aus

20 17 17 Die Testphase beinhaltete die folgenden Schritte. 1. Ausführen von Zero Page Reclaim für die LU. 2. Bereitstellen einer lazyzeroedthick-vmdk mit 100 GB und Konvertierung zu einer eagerzeroedthick-vmdk. 3. Messen des Speicherverbrauchs und der Speicherzuweisung des SAN und von vcenter. 4. Ausführen von Zero Page Reclaim für die LU. 5. Messen des Speicherverbrauchs. Abbildung 6 beschreibt den während dieser Tests verwendeten Speicher. Abbildung 6

21 18 18 Großflächiger Boot Storm mit hardwaregestützter Sperrung Das Ziel dieses Tests war das Erzeugen eines großflächigen Boot Storms durch das gleichzeitige Hochfahren von 400 virtuellen Maschinen. Damit sollte die Leistung bei Verwendung und Nichtverwendung der Stammfunktion für hardwaregestützte Sperrung gezeigt werden, die in Hitachi Unified Storage integriert ist. In diesem Testverfahren wurden 400 virtuelle Linked Clone-Maschinen, die gleichmäßig über vier ESX 5.0-Hosts auf einem gemeinsamen Datenspeicher verteilt waren, gleichzeitig hochgefahren. Dieser Test verwendete die folgenden Komponenten: Einen Dynamic Provisioning-Pool mit 24 Spindeln (HDP-24D) Einen kleineren Dynamic Provisioning-Pool mit 8 Spindeln (HDP-8D), um die Wahrscheinlichkeit von SCSI-Sperrkonflikten zu erhöhen Der Test wurde wie folgt für beide Spindelkonfigurationen durchgeführt: Hardwaregestützte Sperrung aktiviert bei Verwendung des VMSF 5-File-Systems Hardwaregestützte Sperrung deaktiviert bei Verwendung des VMFS 3-File-Systems Die folgenden Daten wurden erfasst: Die Konflikte pro Sekunde wurden von jedem Host mithilfe von ESXTOP erfasst und auf die Anzahl der SCSI-Reservierungssperrkonflikte überprüft, um die Anzahl der SCSI-Sperrkonflikte zu bestimmen. Die verstrichene Zeit wurde vom vsphere-client erfasst, um die für vollständige Einschaltvorgänge benötigte Zeit zu messen.

22 19 19 Abbildung 7 zeigt das Speicherlayout. Abbildung 7 Großflächiges simultanes vmotion mit hardwaregestützter Sperrung Das Ziel dieses Tests ist die Simulation eines unterbrechungsfreien Upgrades, um das Leistungsprofil von Hitachi Unified Storage bei Verwendung der Stammfunktion für hardwaregestützte Sperrung zu erfassen. In diesem Testverfahren werden 100 virtuelle Maschinen verschiedener Klassen (Linked Clones, Thin Provisioning-gestützte virtuelle Maschinen und virtuelle Maschinen mit Snapshots) gleichmäßig über vier ESX 5.0-Hosts hinweg bereitgestellt. Um ein unterbrechungsfreies Upgrade oder geplante Ausfallzeiten zu simulieren, wird ein einzelner Host in den Wartungsmodus versetzt. Dadurch ist VMware vmotion gezwungen, die virtuellen Maschinen von diesem Host auf die drei verbliebenen Hosts im Cluster zu verschieben. Nachdem alle virtuellen Maschinen von diesem Host entfernt wurden, wird er wieder online gestellt. Dieser Vorgang wird auf allen vier Hosts bei aktivierter und deaktivierter hardwaregestützten Sperrung wiederholt. Der vsphere-client erfasst die von vmotion benötigte Zeit, um alle virtuellen Maschinen von jedem Host zu entfernen. ESXTOP erfasste die Konflikte pro Sekunde jedes Hosts, um die Anzahl der SCSI-Reservierungssperrkonflikte zu bestimmen. Der vsphere-client erfasste die für vollständige Einschaltvorgänge benötigte Zeit.

23 20 20 Abbildung 8 zeigt das Speicherlayout: Abbildung 8 Thin Provisioning Stun Das Ziel dieses Tests war die erhöhte Auslastung der Hitachi Dynamic Provisioning-Poolkapazität. In diesem Testverfahren wurde ein überprovisionierter Hitachi Dynamic Provisioning-Pool erstellt. Das VDBench-Dienstprogramm wurde innerhalb einer virtuellen Maschine installiert, um die virtuelle Festplatte über die Begrenzungen des provisionierten VMDK-Speichers hinaus zu beschreiben. Die folgenden Einstellungen wurden auf dem Hitachi Unified Storage vorgenommen: Hostgruppen-Optionen: Festlegen von DP Depletion Detail Reply Mode auf Yes. Dynamic Provisioning-Pool Warnung für verbrauchte Kapazität: Festlegen von Early Alert auf 50 %. Festlegen von Depletion Alert auf 70 %. Die folgende Prozedur wurde in diesem Test angewandt. 1. Erstellen eines Speichers mit einer 100 GB-LUN. 2. Erstellen der VMDK. 3. Verbinden der VMDK mit der virtuellen Maschine.

24 Ausführen von VDBench, um Schreibvorgänge von 100 % auf die Festplatte zu ermöglichen. 5. Bewertung der Fehlermeldungen. 6. Erweitern des LUN-Speichers, um Schreibvorgänge zuzulassen.

25 22 22 Analyse Es folgt die Analyse der Testergebnisse. Klonen mit vollständiger Kopie Der Test für das Klonen mit vollständiger Kopie ergab Folgendes: Die Verwendung der Stammfunktion für vollständige Kopien verbessert die Effizienz durch die Verkürzung der Bereitstellungsfristen, die für die Provisionierung virtueller Maschinen nötig sind. Maßgebliche Verbesserungen können an einer VMDK im Thin-Format beobachtet werden. Befehle für vollständige Kopien haben eine deutlich geringere E/A- Auswirkung auf den ESX-Host. Dadurch werden HBA-Ressourcen freigesetzt, die dem Host für andere Vorgänge zur Verfügung stehen. Die Verwendung der Stammfunktion für vollständige Kopien verringerte die Anzahl der vom Host-HBA verbrauchten IOPS. Die Stammfunktion für vollständige Kopien reduziert E/A hostseitig während gängiger Aufgaben wie den Folgenden: Die Verschiebung virtueller Maschinen mit Storage vmotion Die Bereitstellung einer neuen virtuellen Maschine aus einer Vorlage durch die Anweisung an das Speichersystem, Daten innerhalb des Speichersystems zu kopieren, anstatt den Datenfluss hin und her zu den ESX-Hosts zu schicken Festplattenauslastung bei Blockeliminierung mit Hitachi Dynamic Provisioning Der Test für die Blockeliminierung ergab das Folgende: Die Provisionierung mit aktiviertem VAAI ist in allen Fällen schneller, in denen der Dynamic Provisioning-Pool keine verschmutzten Speicherseiten enthält. Das Zero Page Reclaim-Dienstprogramm optimiert die Provisionierung maßgeblich, wenn Speicher innerhalb eines Pools zurückgewonnen wird, indem der Speicher von unbenutzten Seiten befreit wird, um eine flexiblere und schnellere Kongruenz zu ermöglichen. Eine VMDK im eagerzeroedthick-format funktioniert ohne Leistungseinbußen von ESX oder Hitachi Unified Storage, sobald diese bereitgestellt werden. Soll die Menge an Schreibvorgängen auf ein Speichergerät ohne Änderungen an der Blockzuweisung reduziert werden, ist lazyzeroedthick die beste Alternative, da die Überschreibung mit Nullbytes bei der anfänglichen Beschreibung stattfindet.

26 23 23 Die Stammfunktion für Blockeliminierung beschleunigt die Bereitstellung von virtuellen Maschinen durch die Auslagerung der Eliminierung einer großen Anzahl an Blöcken in das Speichersystem, wodurch die Ressourcen des ESX-Hosts für andere Aufgaben zur Verfügung stehen. Hardwarebeschleunigtes Thin Provisioning wird bei der Verwendung von VAAI mit Hitachi Dynamic Provisioning erreicht, wie in Tabelle 7 dargestellt. Tabelle 7. Thin Provisioning und Zustände der Stammfunktionen auf Hitachi Dynamic Provisioning Zustand der Stammfunktion Thin-VMDK Lazyzeroedthick- VMDK Eagerzeroedthick- VMDK VAAI AKTIVIERT Thin Provisioning Thin Provisioning Thin Provisioning VAAI DEAKTIVIERT Thin Provisioning Thin Provisioning Thick Provisioning Großflächiger Boot Storm mit hardwaregestützter Sperrung Die Ergebnisse dieses Tests zeigen, dass ein Datenspeicher mit einer reduzierten Anzahl an Spindeln anfällig für vermehrte Sperrungen ist. Diese vermehrten Sperrungen können die Leistung beeinträchtigen und die Anzahl der virtuellen Maschinen begrenzen, die auf einem einzigen Datenspeicher betrieben werden können. Die Verwendung der Stammfunktion für hardwaregestützte Sperrung verbessert die Skalierbarkeit von vsphere beträchtlich, indem eine größere Anzahl virtueller Maschinen pro Datenspeicher gleichzeitig betrieben werden kann. Das gleichzeitige Betreiben mehrerer virtueller Maschinen in einem Datenspeicher ermöglicht eine Berücksichtigung größerer VMFS-Volumes. Die aktivierte Stammfunktion für hardwaregestützte Sperrung verringert die Wahrscheinlichkeit von SCSI-Reservierungssperrkonflikten bei alltäglichen Aufgaben wie Storage vmotion, Erstellen oder Löschen von VMDK-Dateien und Herauf- oder Herunterfahren von virtuellen Maschinen beträchtlich. Großflächiges simultanes vmotion mit hardwaregestützter Sperrung Hardwaregestützte Sperrung reduziert die von vmotion benötigte Zeit für eine umfangreiche Auslagerung der VMFS-Metadatensicherung zu Hitachi Unified Storage. Durch den geringeren Zeitaufwand von vmotion kann auch die Zeit für Wartungsfenster verkürzt werden.

27 24 24 Thin Provisioning Stun Der Test mit Thin Provisioning Stun ergab das Folgende: Die Thin Provisioning Stun-Stammfunktion ermöglicht die Wiederaufnahme des Betriebs auch bei vollem Speicher. Es wird empfohlen, TP Stun in allen Fällen zu aktivieren, bei denen die Datenintegrität äußerst entscheidend für die Vermeidung eines potenziellen Datenverlusts ist. Die passende Einstellung der Warnung für fehlenden Speicher kann Ihnen die Flexibilität verleihen, die für eine Erholung von umfangreichen Problemen mit Speicherwachstum nötig ist. Stellen Sie die Frühwarnung ein, um potenzielle Störungen so früh wie möglich zu erfassen.

28 25 25 Vollständige Testergebnisse Dies sind die Ergebnisse des Prüfverfahrens. Klonen mit vollständiger Kopie Abbildung 9 zeigt die benötigte Zeit für die Vollendung des Klonens bei aktiviertem und deaktiviertem VAAI. Abbildung 9 Bei deaktiviertem VAAI wurde das Klonen der virtuellen Maschine im lazyzeroedthick-format mit 30 GB in 42 Sekunden fertiggestellt. Bei aktiviertem VAAI wurde das Klonen der virtuellen Maschine im lazyzeroedthick-format mit 30 GB in 36 Sekunden fertiggestellt, ein Rückgang um 14,29 Prozent. Bei deaktiviertem VAAI wurde das Klonen der virtuellen Maschine im eagerzeroedthick-format mit 30 GB in 94 Sekunden fertiggestellt. Bei aktiviertem VAAI wurde das Klonen der virtuellen Maschine im eagerzeroedthick-format mit 30 GB in 94 Sekunden fertiggestellt, ein Rückgang um 0 Prozent. Bei deaktiviertem VAAI wurde das Klonen der virtuellen Maschine im Thin-Format mit 30 GB in 90 Sekunden fertiggestellt. Bei aktiviertem VAAI wurde das Klonen der virtuellen Maschine im Thin-Format mit 30 GB in 65 Sekunden fertiggestellt, ein Rückgang um 27,78 Prozent. Lazyzeroedthick ist am schnellsten bereitzustellen.

29 26 26 Abbildung 10 zeigt die Ergebnisse des Tests für vollständige Kopien mit der Anzahl der verbrauchten IOPS, die auf dem ESX-Host-HBA erfasst wurden. Abbildung 10 Abbildung 10 zeigt, dass die Stammfunktion für vollständige Kopien die Anzahl der vom Host-HBA verbrauchten IOPS um mehr als 90 Prozent reduziert hat. Bei aktiviertem VAAI wurden fast alle IOPS des Klonverfahrens aus den ESX- Hosts zum Speichersystem ausgelagert. Bei deaktiviertem VAAI zeigte der Test eine anhaltende Steigerung in der Anzahl der IOPS auf dem ESX-Host.

30 27 27 Abbildung 11 zeigt die insgesamt bei allen Testverfahren verbrauchten IOPS. Abbildung 11

31 28 28 Abbildung 12 zeigt, dass das Klonverfahren bei aktivierter Stammfunktion für vollständige Kopien 92 % weniger E/A verbraucht hat. Abbildung 12

32 29 29 Festplattenauslastung bei Blockeliminierung mit Hitachi Dynamic Provisioning Dies sind die Ergebnisse des Tests zur Festplattenauslastung bei Blockeliminierung. Bereitstellung eines frischen Dynamic Provisioning-Volumes Da der Speicher vom Controller auf der LUN bereitgestellt wird und eagerzeroedthick auf dem ESX-Host ausgewählt ist, besteht die einzige Möglichkeit der Provisionierung als Thin durch das SAN darin, dass der Host über VAAI kommuniziert, um Hitachi Unified Storage zu informieren, dass die VMDK selbst leer ist. Dies zeigen Abbildung 13 und Abbildung 14. Abbildung 13 Abbildung 14

33 30 30 Bereitstellung eines zu 100 % verschmutzten Dynamic Provisioning-Volumes Dieser nicht optimierte verschmutzte Speicher funktioniert, als wäre er unabhängig von VAAI-Einstellungen Thick Provisioning-gestützt, und verlängert die Provisionierungsdauer um 10 Sekunden. Abbildung 15 zeigt die bestehende VMDK-Datei im eagerzeroedthick-format auf einem Dynamic Provisioning-Volume vor und nach einem Zero Page Reclaim-Vorgang. Abbildung 15 Performance der Blockeliminierung beim Aufwärmen Die Tests zeigen, dass ein beträchtlicher Unterschied zwischen Speicherprovisionierung bei aktiviertem und deaktiviertem VAAI besteht.

34 31 31 Die auffallendste in diesen Tests erlangte Leistungskennzahl war, dass die eagerzeroedthick-provisionierung bei aktiviertem oder deaktiviertem VAAI aufgrund ihrer unmittelbaren Verfügbarkeit und ihres Mangels an nennenswerter Latenzzeit am besten abschnitt. Abbildung 16 macht dies deutlich. Abbildung 16 Abbildung 16 zeigt, dass bei Verwendung von eagerzeroedthick in Kombination mit aktiviertem VAAI und Hitachi Unified Storage Folgendes zutrifft: Automatisches Thin Provisioning vom SAN aus wird auf ein Mindestmaß beschränkt IOPS sind zu 100 % unmittelbar verfügbar, ohne Leistungsverlust Bei virtuellen Festplatten im Thin- und lazyzeroedthick-format fällt bei anfänglichen Schreibvorgängen ein Overhead für die Aufwärmphase an, was zu dem Overhead und der Latenz in Abbildung 17 und Abbildung 18 führt. Virtuelle Festplatten im Thin-Format weisen im Vergleich zu solchen im lazyzeroedthick-format einen höheren Overhead für die Aufwärmphase auf. Verglichen mit virtuellen Festplatten im lazyzeroedthick-format sind solche im Thin-Format jedoch mehr als 2,5-mal schneller bei der vollständigen Eliminierung der Blöcke. Die Eliminierung der Blöcke wird durch die Integration der VAAI- Stammfunktion für Blockeliminierung zu Hitachi Unified Storage ausgelagert. Sobald die Blöcke für virtuelle Festplatten mit Nullbytes überschrieben sind, entstehen keine Leistungseinbußen. Über einen längeren Zeitraum haben virtuelle Festplatten im Thin-, lazyzeroedthick- und eagerzeroedthick-format gleiche Leistungsmerkmale.

35 32 32 Bei aktiviertem und deaktiviertem VAAI steht Thin an zweiter Stelle, da sich die IOPS in weniger als 23 Minuten stabilisierten. Die Latenzzeit betrug weniger als 1 Millisekunde in einem Zeitraum von 9 Minuten, wie Abbildung 17 verdeutlicht. Abbildung 17

36 33 33 Aufgrund von Overhead und Latenz, die durch das doppelte Schreiben bedingt sind, nahm der Aufwärmtest des lazyzeroedthick-formats viel mehr Zeit in Anspruch als die der anderen Formatoptionen. Dies zeigen Abbildung 18 und Abbildung 19. Vergleichen Sie diese Ergebnisse mit denen in Abbildung 16 und Abbildung 17. Abbildung 18 Abbildung 19 Blockeliminierung mit Zero Page Reclaim Nach dem Zero Page Reclaim-Vorgang wurden 92 GB des Speicherplatzes im Dynamic Provisioning-Pool freigesetzt. Infolgedessen wurden der virtuellen Maschine nach dem Zero Page Reclaim-Vorgang dennoch die ursprünglichen 100 GB zugewiesen, doch auf dem Speichersystem verbrauchte sie nur 8 GB Speicherplatz.

37 34 34 Mithilfe des vsphere-clients wurde die Provisionierungsdauer erfasst. Abbildung 20 zeigt, dass bei aktiviertem VAAI die benötigte Zeit für die Provisionierung einer eagerzeroedthick-vmdk-datei mit 30 GB um 85 Prozent reduziert wird. Abbildung 20 Großflächiger Boot Storm mit hardwaregestützter Sperrung Abbildung 21 zeigt, dass sich die Hochfahrdauer bei aktiviertem VAAI um 3,8 Prozent verringerte, wenn der Datenspeicher auf dem Dynamic Provisioning- Pool mit 24 Spindeln verwendet wurde. Sie verringerte sich um 10 Prozent, wenn der Datenspeicher auf einem Dynamic Provisioning-Pool mit 8 Spindeln verwendet wurde. Abbildung 21

38 35 35 Abbildung 22 zeigt, dass die Anzahl von SCSI-Sperrkonflikten bei aktiviertem VAAI für den Datenspeicher auf dem Dynamic Provisioning-Pool mit 24 Spindeln um 100 Prozent abnahm. Für den Datenspeicher auf dem Dynamic Provisioning- Pool mit 8 Spindeln nahm die Anzahl der Konflikte um 99,27 Prozent ab. Abbildung 22

39 36 36 Großflächiger Boot Storm mit hardwaregestützter Sperrung Abbildung 23 zeigt, dass die für die Verschiebung der virtuellen Maschinen von jedem Host benötigte Zeit bei aktiviertem VAAI um bis zu 34 Prozent reduziert wurde. Abbildung 23 Die Verwendung der Stammfunktion für hardwaregestützte Sperrung verringerte durch die Beschleunigung des vmotion-prozesses die Migrationsdauer und minimierte Wartungszyklen. Im Gegenzug werden Ausfallzeiten begrenzt und IT-Vorgänge beschleunigt.

40 37 37 Thin Provisioning Stun Bei aktiviertem VAAI und der Ausschöpfung des Speichers auf dem SAN können die in Abbildung 24 dargestellten Warnungen per oder Konsolen- Protokollierung an den Administrator geschickt werden. Abbildung 24 Bei dem Testen des Thin Provisioning Stun-API schickt ein überprovisionierter Hitachi Dynamic Provisioning-Pool mit ausgelasteter Kapazität zunächst eine Warnung an die Administrationskonsole. Wenn die verbrauchte Kapazität die Alarmschwelle überschreitet, zeigt die virtuelle Maschine das Dialogfeld in Abbildung 25 an, welches Ihnen empfiehlt, freien Festplattenspeicher zu schaffen und es erneut zu versuchen. Abbildung 25 Wenn das Speicherplatzproblem behoben ist, können Sie durch Anklicken von Retry die Wiederaufnahme aller E/A-Schreib- und Lesevorgänge innerhalb der jeweiligen virtuellen Maschine erreichen.

41 38 38 Zusätzliche Informationen über VMware vstorage APIs for Array Integration Dies sind zusätzliche Informationen über VMware vstorage APIs. Vollständige Kopie Hitachi Unified Storage verwendet VAAI zur Auslagerung des Klonverfahrens einer virtuellen Maschine (oder Tausender virtueller Maschinen in virtuellen Desktop-Umgebungen) vom ESX-Host bei der Provisionierung virtueller Maschinen oder der Migration von VMDK-Dateien zwischen Datenspeichern innerhalb eines Storage vmotion verwendenden Speichers. Die folgenden Vorgänge sind einige Beispiele bei Verwendung der Stammfunktion für vollständige Kopien: Provisionierung virtueller Maschinen Quell- und Zielspeicherort befinden sich innerhalb desselben Volumes. Hitachi kann in die API für vollständige Kopien integriert werden, um VMs oder Datenspeicher von einem Golden Image zu klonen. Dieser Prozess reduziert E/A-Vorgänge zwischen den ESX-Knoten und dem Hitachi-Speicher drastisch. Storage vmotion Quell- und Zielspeicherort befinden sich innerhalb des gleichen Speichersystems auf verschiedenen Volumes. Mithilfe dieser Funktion können VMDK-Dateien innerhalb eines Speichersystems zwischen Datenspeichern verschoben werden. Virtuelle Maschinen können zur Vereinfachung des Lastausgleichs oder geplanter Wartungen migriert werden, wobei die Verfügbarkeit erhalten bleibt. Durch die Integration in vollständige Kopien wird die Migrationsdauer der virtuellen Maschinen aufgrund der Auslagerung der Host-E/A für Storage vmotion- Vorgänge beträchtlich beschleunigt.

42 39 39 Abbildung 26 zeigt einen Vergleich der Kopierfunktionen bei aktiviertem und deaktiviertem VAAI. Abbildung 26 Die Stammfunktion für vollständige Kopien ermöglicht einem ESX-Host, die Kopie einer VMDK zwischen einem Quellspeicherort und einem Zielspeicherort innerhalb des Speichersystems zu initiieren, anstatt zwischen dem Host und dem Speichersystem. Dadurch wird die Anzahl der Schreib- und Lesevorgänge des ESX-Hosts verringert und die I/O-Bandbreite bei der Kopie virtueller Maschinen reduziert. Blockeliminierung Ein gängiger Vorgang bei der Erstellung neuer virtueller Maschinen oder virtueller Festplatten ist die Zuweisung von Speicherplatz. Bei Verwendung des lazyzeroedthick-formats wird die Größe der virtuellen Festplatte bereits vor der Erstellung zugewiesen, doch nicht der gesamte Platz wird mit Nullbytes überschrieben. Wenn das Gastbetriebssystem auf die virtuelle Festplatte schreibt, wird der Speicherplatz nach Bedarf durch Nullbytes ersetzt. Bei Verwendung des eagerzeroedthick-formats wird die Größe der virtuellen Festplatte bereits vor der Erstellung zugewiesen und der Platz durch Nullbytes ersetzt. Dadurch kann die Bereitstellung virtueller Festplatten im eagerzeroedthick-format viel mehr Zeit in Anspruch nehmen. Bei der Stammfunktion für Blockeliminierung finden diese Eliminierungsvorgänge innerhalb des Speichersystems statt, ohne dass der Host mehrere Befehle geben muss.

43 40 40 Abbildung 27 zeigt einen Vergleich der Blockeliminierung bei aktiviertem und deaktiviertem VAAI. Abbildung 27 Die Integration in die Stammfunktion für Blockeliminierung ermöglicht die schnelle Provisionierung von VMDKs im eagerzeroedthick- oder lazyzeroedthick-format, indem Nullen über Hunderte oder Tausende Blöcke auf den VMFS- Datenspeichern geschrieben werden. Dadurch wird ein Großteil des Prozesses von den ESX-Hosts in das Speichersystem ausgelagert. Aufgrund der hohen Anzahl an zu eliminierenden Blöcken erweist sich dies als besonders nützlich bei der Provisionierung von eagerzeroedthick-vmdks für fehlertolerante virtuelle Maschinen von VMware. Hinweis Blockeliminierung ist in vsphere 5 mit der VMDK-Version 5 standardmäßig auf 1-MB-Blöcke festgelegt. Alle veränderten Blöcke auf der LUN werden in 1-MB- Inkrementen gemessen. Hardwaregestützte Sperrung Die Integration in die Stammfunktion für hardwaregestützte Sperrung bietet eine präzisere Sperrung der LUN. Sie ermöglicht die atomare Modifizierung einer logischen Blockadresse auf einer virtuellen Festplatte, ohne SCSI- Reservierungen zu verwenden oder die LUN von anderen Hosts aus zu sperren.

44 41 41 Abbildung 28 zeigt einen Vergleich der hardwaregestützten Sperrung bei aktiviertem und deaktiviertem VAAI. Abbildung 28 ESX 5.0-Umgebungen sind auf Sperrmechanismen angewiesen, um VMFS- Metadaten zu schützen. Dies gilt besonders in Cluster-Umgebungen, in denen mehrere ESX-Hosts auf dieselbe LUN zugreifen. ESX verwendet SCSI- Reservierungen, um Hosts an der gleichzeitigen Aktivierung oder Freigabe von virtuellen Festplatteninhalten auf mehreren Hosts zu hindern. Diese SCSI-Sperralgorithmen sperren jedoch eine ganze LUN und verfügen nicht über die zum Sperren eines bestimmten Blocks auf der LUN benötigte Granularität. Dieser Algorithmus erfordert für eine Sperrung vier verschiedene Befehle (einfach ausgedrückt: Reservieren, Lesen, Schreiben und Freigeben). Das Sperren der ganzen LUN kann auch zu SCSI-Reservierungskonflikten führen und die Skalierbarkeit beeinträchtigen. Der Transfer des Sperrprozesses der LUN zu Hitachi Unified Storage verringert die Anzahl der für den Zugriff auf eine Sperrung benötigten Befehle und ermöglicht eine präzisere Sperrung. Dadurch ergibt sich eine bessere Gesamtleistung und eine höhere Anzahl an virtuellen Maschinen pro Datenspeicher sowie eine höhere Anzahl an auf den Datenspeicher zugreifenden Hosts. Mit der Version 5.0 von ESXi kann die Stammfunktion für hardwaregestützte Sperrung bei neu erstellten VMFS 5-File-Systemen auf dem Hitachi Unified Storage nicht deaktiviert werden. Die hardwaregestützte Sperrung kann bei VMFS 3-File-Systemen auf dem Hitachi Unified Storage deaktiviert werden. Weitere Informationen finden Sie unter vstorage API for Array Integration FAQ auf der Website von VMware.

45 42 42 Nachfolgend finden Sie beispielhafte Anwendungsfälle für hardwaregestützte Sperrung: Migration einer virtuellen Maschine mit vmotion Erstellen einer neuen virtuellen Maschine oder Vorlage Bereitstellung einer virtuellen Maschine aus einer Vorlage Hoch- und Herunterfahren einer virtuellen Maschine Erstellen, Löschen oder Erweitern einer Datei Erstellen, Löschen oder Erweitern eines Snapshots Thin Provisioning Stun Thin Provisioning-gestützte Volumes ermöglichen eine Speicherprovisionierung auf Abruf, da sie die Kapazitätsanforderungen des Speichersystems im Laufe seines Betriebs reduzieren. Speichersysteme weisen jedoch eine begrenzte Menge physischer Speicherressourcen für die Unterstützung eines Thin Provisioning-gestützten Volumes auf. Dies erfordert die Überwachung und Früherkennung des Verbrauchs dieser physischen Speicherressourcen. Hitachi Dynamic Provisioning verfügt über einen integrierten Mechanismus, um Speicheradministratoren bei vom Benutzer festgelegten Schwellenwerten zu warnen. Die Integration in die Thin Provisioning Stun-API-Stammfunktion sendet die Warnungen von Hitachi Dynamic Provisioning an den ESX-Host. Bei Erreichen einer Hitachi Dynamic Provisioning-Warnschwelle aufgrund des Speicherverbrauchs zeigt der ESX-Host eine Warnmeldung an. Wenn die Kapazität von Hitachi Dynamic Provisioning erschöpft ist, stoppt ESX die betroffenen virtuellen Maschinen und erstellt ein Ereignisprotokoll. Durch diese beiden Funktionen werden sowohl der Speicheradministrator als auch der vsphere-administrator in Kenntnis gesetzt, um die Integrität der virtuellen Maschine zu wahren.

46 Weitere Informationen Hitachi Data Systems Global Services verfügt über erfahrene Speicherexperten, bewährte Methoden und ein umfangreiches Service-Portfolio, um Sie bei der Implementierung von Hitachi-Produkten und -Lösungen in Ihrer Umgebung zu unterstützen. Weitere Informationen erhalten Sie auf der Website von Hitachi Data Systems Global Services. Für viele Hitachi-Produkte sind aufgezeichnete und Live-Demonstrationen verfügbar. Wenden Sie sich an einen Vertriebsmitarbeiter zur Vereinbarung eines Termins für eine Live-Demonstration. Aufgezeichnete Demonstrationen finden Sie auf der Website von Hitachi Data Systems unter Corporate Resources. Klicken Sie auf die Registerkarte Product Demos, um eine Liste der verfügbaren aufgezeichneten Demonstrationen aufzurufen. Hitachi Data Systems Academy bietet erstklassige Schulungen zu den Produkten, Technologien, Lösungen und Zertifizierungen von Hitachi. Hierzu zählen auf Abruf verfügbare webbasierte Schulungen (WBT), von Dozenten geleitete Präsenzschulungen (ILT) sowie von Dozenten geleitete virtuelle Schulungen (vilt). Weitere Informationen erhalten Sie auf der Website von Hitachi Data Systems unter Services: Education. Wenn Sie mehr über Hitachi-Produkte und -Services erfahren möchten, wenden Sie sich an Ihren Vertriebsmitarbeiter oder Channel-Partner, oder besuchen Sie die Website von Hitachi Data Systems.

47 Hauptniederlassung 750 Central Expressway, Santa Clara, California USA Regionaler Kontakt Nord- und Südamerika: oder Europa, Naher Osten, Afrika: +44 (0) oder Region Asien-Pazifik: oder Hitachi ist in den USA und anderen Ländern eine eingetragene Marke von Hitachi, Ltd. Hitachi Data Systems ist in den USA und anderen Ländern eine eingetragene Marke und Dienstleistungsmarke von Hitachi, Ltd. Alle anderen in diesem Dokument bzw. auf dieser Website erwähnten Marken, Dienstleistungsmarken und Unternehmensnamen sind Eigentum der jeweiligen Inhaber. Hinweis: Dieses Dokument dient ausschließlich zu Informationszwecken und beinhaltet keine ausdrückliche oder stillschweigende Garantie für Geräte oder Dienstleistungen, die von Hitachi Data Systems Corporation aktuell oder künftig angeboten werden. Hitachi Data Systems Corporation Alle Rechte vorbehalten. AS , August 2012