Mit Storage I/O Control (SIOC) werden E/A-Vorgänge von virtuellen Maschinen priorisiert, die auf einer VMware vSphere-Host-Gruppe mit Zugriff auf einen Shared Storage-Pool ausgeführt werden. Die Lösung erweitert die bekannten Freigaben und Beschränkungen für die CPU und den Arbeitsspeicher. So wird mit ihr über eine dynamische Zuweisung der E/A-Kapazität in einem vSphere-Host-Cluster eine optimale Storage-Auslastung erreicht. Storage I/O Control vereinfacht die Bereitstellung von Infrastrukturservices und demzufolge von Cloud Computing erheblich.

• Anpassung von Storage-Ressourcen an geschäftliche Anforderungen
• Automatische Storage-Zuweisung

Über selbst konfigurierte Regeln und Richtlinien geben Sie die Geschäftspriorität jeder einzelnen virtuellen Maschine an. Bei E/A-Konflikten weist Storage I/O Control die verfügbaren E/A-Ressourcen gemäß Ihren Regeln dynamisch den virtuellen Maschinen zu. Auf diese Weise werden die Service-Level für kritische Anwendungen verbessert und mehr Arten von Workloads, darunter E/A-intensive Anwendungen, können virtualisiert werden.

• Freigaben und Beschränkungen der Storage-Ressourcen festlegen, anzeigen und überwachen
• Storage-Prioritäten (pro virtuelle Maschine) in einer ganzen Gruppe von vSphere-Hosts festlegen und durchsetzen
• Storage-Volumes müssen seltener für einzelne Anwendungen reserviert werden, wodurch Flexibilität und Agilität der Infrastruktur verbessert werden

Steigerung der Administratorproduktivität durch Reduzierung des Umfangs des aktiven Performance-Managements.

• Die Aktivierung von Storage I/O Control für einen Datastore ermöglicht die Überwachung der Gerätelatenz, die Hosts bei der Kommunikation mit diesem Datastore feststellen.
• Wenn die Latenz einen festgelegten Schwellwert überschreitet, gilt der Datastore als überlastet und die Funktion wird automatisch aktiviert. Jeder virtuellen Maschine, die auf den Datastore zugreift, werden dann je nach ihrem Anteil E/A-Ressourcen zugewiesen.

Storage I/O Control ist in der VMware vSphere Enterprise Plus Edition  enthalten.

Mit Storage I/O Control (SIOC) werden E/A-Vorgänge von virtuellen Maschinen priorisiert, die auf einer VMware vSphere-Host-Gruppe mit Zugriff auf einen Shared Storage-Pool ausgeführt werden. Die Lösung erweitert die bekannten Freigaben und Beschränkungen für die CPU und den Arbeitsspeicher. So wird mit ihr über eine dynamische Zuweisung der E/A-Warteschlangen-Slots in einer Servergruppe eine optimale Storage-Auslastung erreicht.

Herkömmliche CPU- und Arbeitsspeicherfreigaben sprechen die Ressourcen eines einzelnen ESXi-Hosts an. Die virtuellen Maschinen stehen dabei im Wettbewerb um die begrenzten Arbeitsspeicher- und CPU-Ressourcen eines Hosts. Bei Shared Storage-Ressourcen in einer vSphere-Infrastruktur wird, wie der Name schon andeutet, der Storage geteilt. Aus diesem Grund muss vSphere den Zugriff auf Storage über mehrere Hosts realisieren und darf ihn nicht auf einzelne Hosts beschränken. Die Grenze für den Betrieb von SIOC stellt eine Gruppe aus Hosts dar, die einen Datastore gemeinsam nutzen und von einer vCenter Server-Instanz verwaltet werden. Anhand der folgenden Abbildungen werden die Unterschiede zwischen dem Zugriff auf den Storage auf Host-Ebene und dem Zugriff über eine Gruppe von Hosts, die Datastores gemeinsam nutzen, verdeutlicht.

Die folgende Abbildung zeigt drei virtuelle Maschinen. VM001 und VM002 werden auf ESX01 gehostet. VM003 hingegen wird auf ESX02 gehostet. Alle virtuellen Maschinen weisen Festplattenfreigaben mit einem Wert von 1000 auf. In diesem Beispiel ist Storage I/O Control deaktiviert. Es liegt also kein Mechanismus vor, der die E/A-Vorgänge auf Datastore-Ebene reguliert. Unten in der Abbildung befindet sich die Storage-Array-Warteschlange. Diese steht für die tatsächlichen Lese- und Schreibvorgänge, die zur Verarbeitung an das Storage-Array gesendet werden. Wie Sie sehen können, erhält VM003 mehr Ressourcen als VM001 und VM002, obwohl alle drei virtuellen Maschinen denselben Freigabewert für Storage-Ressourcen aufweisen. Dies liegt daran, dass VM003 auf alle Storage-Ressourcen auf Host ESX02 zugreifen kann, während VM001 und VM002 die Ressourcen von Host ESX01 gemeinsam nutzen.

In der nächsten Abbildung ist Storage I/O Control aktiviert. In diesem Fall wird bei Konflikten der E/A-Zugriff aller virtuellen Maschinen, die auf einen bestimmten Datastore zugreifen, nicht durch den Host, sondern durch den jeweiligen Freigabewert beschränkt. Wie Sie sehen können, ist VM003 jetzt durch den Freigabewert von 1000 beschränkt.

Ist Storage I/O Control für einen bestimmten Datastore aktiviert, wird dieser Datastore überwacht. Bei Überschreitung des angegebenen Latenzschwellwerts des Datastores (Standard: durchschnittliche E/A-Latenz von 30 ms) wird SIOC aktiv, um das mögliche Ungleichgewicht zu beseitigen. Dafür beschränkt SIOC die Menge der E/A-Operationen, die ein Host für den jeweiligen Datastore anregen kann. Dies geschieht durch die Drosselung der Host-Gerätewarteschlange (siehe „Tiefe der Gerätewarteschlange“ im Schaubild). In diesem Beispiel wurde die Tiefe der Gerätewarteschlange von ESX02 auf 16 abgesenkt.

Storage I/O Control fungiert als „Datastore-weiter Festplattenplaner“. Ist SIOC für einen Datastore aktiviert, werden die Festplattenfreigaben für die einzelnen VMDK-Dateien auf dem Datastore addiert. Im Anschluss berechnet SIOC die E/A-Slot-Berechtigung je ESXi-Host. Dafür wird der Prozentsatz der Freigaben der virtuellen Maschinen, die auf diesem Host ausgeführt werden, in Relation zu den Gesamtfreigaben aller Hosts mit Zugriff auf diesen Datastore gesetzt.

Damit Storage I/O Control die E/A-Vorgänge für einen bestimmten Datastore optimieren kann, müssen zwei Bedingungen erfüllt sein:

1. Die Funktion muss für den Datastore aktiviert sein (durch die Konfiguration der Eigenschafteneinstellung des Datastores).
2. Die vSphere-Hosts, die den Datastore gemeinsam nutzen, müssen dauerhaft eine durchschnittliche Latenz aufweisen. Der Standardschwellwert von 30 ms kann über die erweiterten Einstellungen der Datastore-Eigenschaften angepasst werden.

Sind diese beiden Bedingungen erfüllt, verwaltet SIOC proaktiv die E/A-Warteschlangen aller ESXi-Server, die diesen Datastore gemeinsam nutzen.

vSphere 5.0-Verbesserungen

vSphere 5.0 Storage I/O Control unterstützt Freigaben und Beschränkungen für blockbasierte Datastores und NFS-Datastores. Das heißt, dass keine einzelne virtuelle Maschine einen Engpass in einer Umgebung verursachen können sollte, ungeachtet des Typs von Shared Storage.

Der Standardschwellwert für die Latenz bei SIOC liegt bei 30 ms. Da nicht alle Storage-Geräte gleich sind, liegt dieser Standardwert in der Mitte der möglichen Werte. Bei bestimmten Geräten tritt der Konfliktzustand früher ein als bei anderen Geräten. Dies ist beispielsweise bei SSDs der Fall, weshalb bei diesen Geräten der Schwellwert verringert werden sollte.

Die manuelle Bestimmung der richtigen Latenz kann sich jedoch als schwierig erweisen. Aus diesem Grund sollte der Latenzschwellwert für jedes Gerät automatisch bestimmbar sein. Anstatt einen Standardschwellwert für die Latenz anzugeben oder den Wert vom Anwender bestimmen zu lassen, kann vSphere 5.1 SIOC den optimalen Schwellwert für einen Datastore automatisch bestimmen.

Der Latenzschwellwert wird auf den Wert festgelegt, der vom E/A-Injektor (Teil von SIOC) ermittelt wird. Über die Berechnung des Spitzendurchsatzes ermittelt der E/A-Injektor den Wert für 90 Prozent Durchsatz. Von diesem Wert ausgehend wird dann die Latenz gemessen und der Schwellwert bestimmt.

vSphere-Administratoren können anstelle der 90 Prozent einen anderen Wert angeben oder alternativ eine Zeitangabe in Millisekunden machen.

Bei vSphere 5.1 ist SIOC automatisch bei allen Datastores im reinen Statistikmodus aktiviert. Dies hat zur Folge, dass Storage-Statistiken, die für gewöhnlich nur bei aktiviertem SIOC angezeigt werden, ab sofort unmittelbar verfügbar sind. Des Weiteren bietet Storage DRS jetzt auch Statistiken im Voraus für Datastores, die neu zu einem Datastore-Cluster hinzugefügt werden.

VmObservedLatency ist eine neue SIOC-Kennzahl, die mit vSphere 5.1 eingeführt wurde. Sie ersetzt die Kennzahl für die Datastore-Latenz aus früheren Versionen. Mit der neuen Kennzahl wird die Zeit zwischen dem Eingang der E/A-Vorgänge von der virtuellen Maschine am VMkernel und dem Eingang der Antwort vom Datastore gemessen. Bislang wurde die Latenz lediglich erfasst, nachdem die E/A-Vorgänge den ESXi-Host verlassen haben. Mit der neuen Kennzahl wird die Latenz hingegen auch im Host gemessen. Die neue Kennzahl ist im vSphere Client™ sichtbar.