Latenz-optimierte Speicherverwaltung mit QoS auf VM-Ebene

München, Starnberg, 18. Sept. 2015 – Ein Gastbeitrag zum Thema "Virtual Machine - zentrierter Speicher" für Quality-of-Service (QoS) auf VM- und nicht nur LUN-Level...

Zum Beitrag von Mark Young*, Director Systems Engineering EMEA bei Tintri: "Quality of Service (QoS) ist beileibe nichts Neues im Rechenzentrum. Als Information Lifecycle Management vor rund einem Jahrzehnt hoch gehandelt wurde, war QoS bereits ein wichtiger Faktor, allerdings erst für physische Server. Heute, nach der „virtuellen“ Revolution kämpfen Admins wieder damit, QoS zu garantieren. Doch diesmal für ihre kritischen VMs. Dabei stehen sie meist auf verlorenem Posten, da ihre traditionellen Speicher mit veralteten Speicherkonzepten wie LUNs und Volumes arbeiten, die Speicherressourcen von VMs eben nicht auf VM-Ebene verwalten können.

• IT-Administratoren benötigen Werkzeuge, die es Ihnen nicht nur erlauben, diese kritischen VMs einfach zu verwalten, sondern auch das allgemeine Rätselraten von QoS-Einstellungen zu beenden. Mit traditionellen Werkzeugen ist es nur möglich, QoS auf LUN-Ebene einzustellen, was Admins dazu zwingt, Performance über Dutzende oder Hunderte sehr unterschiedliche VMs zu verteilen.
• Neue, intelligentere Speicherlösungen ermöglichen es, QoS für jede individuelle VM zu setzen und stellen sicher, dass jede genau die IOPS bekommt, die sie benötigt. Nicht zu viel und auch nicht zu wenig.

Warum ist traditioneller Speicher bei QoS limitiert?

Das Problem mit konventionellem QoS ist, dass sie nur auf Volume-Ebene funktioniert. Will man also ein Minimum oder Maximum an IOPS setzen, so ist dies nur für ein LUN oder Volume möglich und alle, sehr unterschiedliche VMs, die in diesen Einheiten laufen, bekommen die selbe QoS. Setzt man diese Einstellungen falsch, bekommt man es meist erst mit, wenn sich die Nutzer beschweren. Admins benötigen VM-zentrischen Speicher, der QoS auf VM-Ebene garantiert. VM-zentrischer Speicher bietet volle Einsicht in jede einzelne VM, nicht nur LUNs und/oder Volumes. Dabei ist es möglich, die Latenz auf jeden Teil des Systems herunterzubrechen.

• Die Gesamtlatenz des Hypervisors in Host-Latenz, Netzwerk-Latenz und Latenz des Speichers. Letztere wird noch einmal in separate Anteile aufgebrochen: Contention-Latenz (die Latenz, die durch die 100% Auslastung des Systems entsteht), Latenz des Flash-Anteils, Latenz des Disk-Anteils und Latenz durch Throttling. Die vielen Details, die das Dashboard eines VM-zentrischen Speichers bietet, verdeutlichen die Performance eines Systems und der QoS jeder darauf laufenden VM. Mit der Fähigkeit QoS auf VM-Ebene zu verwalten gibt es keine unkontrollierten, Ressourcen fressende VMs mehr, und jede VM bekommt ihren eigenen, klaren Anteil an Performance-Ressourcen.

Wie sieht das in der Praxis aus?

Ein absoluter Klassiker: die Nutzer beklagen sich darüber, dass Exchange langsam ist und ein Support-Ticket wird erstellt. Mit einem alten System würde nun die langwierige Problemsuche beginnen. Mit einem VM-zentrischen System ist die Lösung des Problems ein Kinderspiel. Alle VMs sind in der Übersicht des Dashboards gelistet und eine unkontrollierte, Bandbreite fressende VM ist sehr einfach zu finden. Es stellt sich also eher die Frage, was man mit ihr tun soll. Auf einem VM-zentrischen System setzt man einfach eine QoS-Grenze für solch eine „wilde“ VM, um sie unter Kontrolle zu bringen. Dabei werden die IOPS, die diese VM verbraucht, sogar in Echtzeit angezeigt. QoS zu konfigurieren geschieht einfach mit einem Rechte-Mausklick auf diese VM und der Einstellung von maximalen IOPS, die diese verbrauchen kann. Jedes Problem mit QoS von VMs kann so innerhalb von Minuten gelöst werden.

Das Resultat ist für den Admin sofort in der Übersicht sichtbar – und in schnellerem Exchange für die Nutzer, die das Problem gemeldet hatten.

Grafik 1 - Vorher/nachher: Eine wilde VM verbrauchte zu viele IOPS und wird per Mausklick zu Räson gebracht

Ein weiteres Beispiel: Viele Unternehmen haben einige Server und Applikationen, die als absolut wichtig gelten und deren VMs jederzeit höchste Performance garantiert bekommen sollten. Läuft eine solche VM langsam, muss der Fehler schnell gefunden und behoben werden. In unserem Beispiel reicht ein Klick auf die VM, um zu zeigen, dass eine Contention-Latenz besteht, dass sich die VM also quasi mit einer oder mehreren anderen VMs um IOPS streitet. Genauso einfach, wie man ein Maximum für wilde VMs setzen kann, kann man mit einem VM-zentrischen Speicher auch ein IOPS-Minimum garantieren.

Das Prinzip bleibt das gleiche: Mit einem Rechte-Mausklick auf die VM kann man QoS einstellen und ein Minimum setzen. Damit ist der Streit um Ressourcen beendet, und die wichtige VM läuft wieder einwandfrei.

Grafik 2 - Vorher/nachher: Eine kritische VM kämpft um Ressourcen und wird per Mausklick mit mehr Minimum IOPS auf Trab gebracht

QoS-Verwaltung auf alten Systemen, die auf LUNs und Volumes setzen, ist nicht sinnvoll wenn einem VMs und Applikationen wichtig sind. VM-zentrischer Speicher gibt dem Admin volle Kontrolle über die Performance einzelner VMs oder bestimmter Gruppen von „Service Tiers“ und spart Zeit und Geld.

 

Grafik 3 – Service Tiers: Die Gruppierung von VMs in unterschiedliche Tiers hilft bei der Verwaltung vieler VMs

Speicher einzusetzen, der nicht VM-zentrisch ist und der nur teuren Flash-Speicher überprovisioniert, um einfach allen VMs höchste Performance zu garantieren, greift zu kurz. Im Zeitalter virtualisierter Rechenzentren ist Speicher gefragt, der Speicher-Performance auf VM-Ebene garantieren kann."

---

*Über den Autor:

Mark Young ist Director Systems Engineering EMEA bei Tintri. Young hat drei Jahrzehnte Erfahrung bei der Entwicklung von neuen Technologien. Bevor Young 2011 zum Unternehmen kam war er Technical Alliance Manager EMEA bei Riverbed und hielt im Lauf seiner Karriere Positionen bei verschiedenen Netzwerk- und Storagefirmen wie Cisco, Corvil und Dell.