xy - Fotolia
Funktionsweise und Aktivierung von Storage I/O-Control für vSphere 6
Storage I/O-Control hilft bei der effizienteren Storage-Nutzung in vSphere 6. Ein Überblick über Funktionsweise und Aktivierung.
VMwares Virtualisierungsplattform vSphere 6 bietet mit Storage I/O-Control eine wirkungsvolle Funktion zum Ressourcen-Management, mit der sich Storage wesentlich effizienter nutzen lässt. Während im ersten Artikel dieses Zweiteilers als Voraussetzung für Storage I/O-Control der Kernel-Storage-Stack von vSphere 6 vorgestellt wurde, wirft dieser zweite Artikel einen genaueren Blick auf die Aktivierung und Nutzung von Storage I/O-Control.
Ähnlich wie bei CPU und Memory erlaubt vSphere seit der Version 4.1 auch beim Erstellen vom VMDK-Disks (Virtual Machine Disk) eine Ressourcenkontrolle in Form von Shares, Limits und Reservations. Doch obwohl sich beide Funktionen hinsichtlich des Einsatzzwecks auf den ersten Blick ähneln, besteht doch ein erheblicher Unterschied zwischen der Priorisierung von Storage und den Ressourcen-Kontrollmöglichkeiten von CPU und Memory, für die letztendlich der CPU-Scheduler beziehungsweise der Memory Allocator im VMkernel zuständig ist.
Das liegt vor allem daran, dass es wesentlich komplizierter ist, die Storage-Kommunikation auf der Seite von vSphere zu messen und zu kontrollieren, wobei man noch zwischen Datenübertragungsmengen (OPS) und Latenzzeiten (in ms) unterscheiden muss. Zwar war das Zuweisen von Ressourcen-Kontrollmechanismen zum Priorisieren einzelner VMDK-Disks auch schon „vor“ Storage I/O-Control möglich, jedoch führten die hier getroffenen Einstellungen mitunter nicht zum angestrebten Erfolg, weil eben doch ein großer Unterschied zwischen dem Priorisieren auf VMDK-Ebene und auf Storage-Ebene besteht, wie folgendes Beispiel zeigt.
Ohne Storage I/O-Control am Ziel vorbei
Hat man etwa zwei ESX-Hosts, die beide mit der gleichen LUN (Logical Unit Number) verbunden sind, müssen sich zwei Device-Queues auf den beiden ESXi-Servern die gleiche Storage-IO-Queue teilen. Das hat folgenden Effekt: Laufen etwa auf ESXi-Host 1 zwei virtuelle Maschinen A und B mit 1.500 und 500 Shares auf ihren jeweiligen VMDK-Dateien, würde der IO der Device-Queue im Verhältnis 3:1 (75 Prozent zu 25 Prozent) aufgeteilt.
Läuft auf dem zweiten ESXi-Host eine VM C mit ebenfalls 500 Shares (diese sollte dann hinsichtlich der IO-Ressourcen gleichberechtig mit VM B auf Host 1 sein), kann diese die Device-Queue auf dem Host zu 100 Prozent für sich alleine nutzen. Setzt man weiterhin voraus, dass beide Device-Queues mit der gleichen Queue-Tiefe (zum Beispiel 12) konfiguriert sind, resultiert daraus auf der Storage-Array-Queue ein Verhältnis von:
0,75 x 50% = 37,5% für VM A
0,25 x 50% = 12,5% für VM B
1 x 50% = 50% für VM C
Das entspricht aber nicht dem eigentlichen Konfigurationswunsch, denn VM B und VM C haben ja je 500 Shares und sollten daher die gleichen Anteile der Storage-Array-Queue beanspruchen. Mittels Storage I/O-Control kann vSphere dagegen für die wunschgemäße Verteilung der I/O-Leistung an der Storage-Array-Queue von 60:20:20 sorgen, indem vSphere die Device-Queue-Nutzung auf Host 2 drosselt, wie folgende Abbildung zeigt.
Voraussetzungen für Storage I/O-Control
Um Storage I/O-Control nutzen zu können, sind neben einer vorhandenen Enterprise-Plus-Lizenz für vSphere eine Reihe weiterer Voraussetzungen zu beachten:
- Datastores mit VMFS-Dateisystem (ohne Verwendung von Extents) oder NFS-Datastores,
- sämtliche Komponenten (ESXi-Server und Datastores), auf denen Storage I/O-Control aktiv ist, müssen über das gleiche vCenter verwaltet werden,
- keine RDM-Mappings,
- SAN oder NAS-Array müssen auf der HCL (Hardware Compatibility List) stehen.
Aktivieren von Storage I/O-Control
Das Einschalten und Konfigurieren von Storage I/O-Control ist dagegen relativ einfach und geschieht in zwei Stufen. Im ersten Schritt aktiviert man Storage I/O-Control auf dem entsprechenden Datastore im Reiter Manage im Tab Settings bei General. Nach einem Klick auf Edit kann man das Häkchen bei Enable Storage I/O-Control setzen.
Im gleichen Dialog können Admins außerdem zwischen einem manuellen und automatischen Schwellwert für die Latenzzeit wählen, welche vSphere auf dem Datastore misst und ab der Storage I/O-Control überhaupt aktiv wird. Die Priorisierung wird anhand der Einstellungen für Shares vorgenommen, wie sie in den VM-Einstellungen konfiguriert wurden.
Allerdings empfehlen viele Storage-Hersteller, insbesondere die Einstellung für Congestion Treshold von Ausnahmen abgesehen nicht zu verändern. Ausnahmen wären etwa, wenn am Back-end deutlich schnellere (Flash) oder deutlich langsamere (5400 RPM SATA) Storage-Systeme zum Einsatz kommen. Die eigentliche Priorisierung wird dann wie gehabt auf VMDK-Ebene in der VM vorgenommen, also genau wie ohne Storage I/O-Control beziehungsweise wie bei älteren vSphere-Versionen, die Storage I/O-Control nicht unterstützen.
Storage I/O-Control ist ein sehr nützliches Feature, das sich wie viele vSphere-Funktionen über die GUI relativ einfach aktvieren lässt. Die Implementation ist allerdings komplex, da vSphere unter anderem IOPS- und Latenzen auf den beteiligten Datastores messen und anpassen muss, denn die Ressourcenkontrolle auf Storage-Ebene ist ein komplizierte Vorgang. Hat man einen Datastore-Cluster für Storage-DRS (Distributed Resource Scheduling) eingerichtet, wird Storage I/O-Control übrigens automatisch aktiviert.
Folgen Sie SearchStorage.de auch auf Twitter, Google+, Xing und Facebook!
