Performance virtueller Maschinen hängt nicht nur vom Storage ab

Bei schlechter VM-Performance hat man schnell das Storage als Übeltäter im Verdacht, obwohl auch der Hypervisor dafür verantwortlich sein kann.

Viele Hersteller und ihre Evangelisten haben immer wieder die Vorteile „präferierter“ Lösungen hochgelobt, die langsame virtualisierte Workloads beschleunigen sollen. Diese Diskussion ist meiner Meinung nach etwas aus dem Ruder gelaufen.  

Wenn Sie, wie ich auch, Fakten-basierte Analysen Ihrer IT-Probleme bevorzugen, dann ist dies hier eine Diskussion über Storage in virtuellen Umgebungen, die nicht unterschiedliche Daten verknüpft, vermischt oder anderweitig falsche Schlüsse aus ihnen zieht.

Fast genauso schnell wie Servervirtualisierung als mehr als nur ein Test-Tool in Mode kam, gab es aufkommende Gerüchte über den schlechten Einfluss, den herkömmlicher Storage auf diese Umgebung hat. Wiederholt wurde kommuniziert, dass Storage die Workloads verlangsamt, nachdem sie virtualisiert und in Hypervisor-Umgebungen realisiert wurden.

Es gab aufkommende Gerüchte über den schlechten Einfluss, den herkömmlicher Storage auf diese Umgebung hat.

Diese Verteufelung traditioneller Storage-Systeme konzentrierte sich meist auf die bekannten Defizite dieser Produkte und Topologien. Über Jahre haben Storage-Hersteller ihre Festplatten-Boxen mit proprietären Controllern und proprietären Software-Funktionen ausgestattet, um sowohl den Kunden in einem Lock-in zu binden als auch eine Integration des Wettbewerbs zu verhindern. 

Kombiniert man dies mit der Abneigung der Branche, miteinander zu operieren und im Management einen gemeinsamen Ansatz zu finden, dann hat man alle Zutaten für eine anfällige und teure Infrastruktur zusammen.

Die oben genannten Punkte kann man kaum abstreiten. Die Lage verschlimmerte sich in den frühen 2000er Jahren so sehr, dass Analysten oft ihren Kunden nahe legten, Storage nur von einem Hersteller zu beziehen, in der Hoffnung, diese Homogenität würde ein kohärentes Management gewährleisten. Das ist der Dreh- und Angelpunkt einer Kosten-sensiblen Strategie.

Zusammenfassend kann man sagen, dass nicht zu managendes Storage die Wurzel für viele IT-Probleme war. Es bedeutete oft eine Überverteilung und Unterauslastung der Ressourcen, was den Bedarf an Kapazitäten und somit den CAPEX nach oben trieb. 

Natürlich benötigten die Unternehmen zudem mehr IT-Mitarbeiter mit speziellen Erfahrungen im Bereich der Storage-Architekturen und der Administration, um ihre Systeme und Anbindungen zu verwalten, was wiederum auch den OPEX in die Höhe schnellen ließ.

Ist Storage wirklich Schuld an Engpässen?

Während mit Fug und Recht behauptet werden kann, dass die genannten Eigenschaften den Storage unattraktiv machten und einer Revision bedurften, so erklären sie nicht das Problem der schlechten Performance virtueller Maschinen (VMs).

Und trotzdem bestehen VMware und andere Hypervisor-Hersteller darauf, falsche Beziehungen und kausale Zusammenhänge zwischen der problematischen VM-Performance und proprietärem Storage zu ziehen. Das resultierte 2006 in VMwares vStorage APIs for Array Integration und in dem kürzlich vorgestellten Virtual SAN. Beides adressiert das Performance-Problem nach wie vor so, dass es das „böse“ Storage attackiert.

Es gibt Instanzen, bei denen Storage-Latenzen die Performance der Applikation verlangsamen kann. Dazu gehören die Geschwindigkeit des Storage-Systems sowie das Netzwerk oder die Fabric, die das Storage mit den Servern verbindet. Das ist bekannt und wird normalerweise durch eine Kombination von Caching und parallelen Prozessen abgeschwächt. 

Wenn die Prozessoren heiß laufen, weist dies oft auf ein Problem in der Applikation oder in der Hypervisor-Software hin.

Das Caching sammelt die Writes auf einem schnellen Storage-Layer, was den langsameren Speicher für die Anwendung unsichtbar macht. Parallele Prozesse beschleunigen die Anzahl abzuarbeitender Aufgaben, beispielsweise der I/O-Prozesse, so dass mehr Workloads in weniger Zeit prozessiert werden können.

Es lassen sich verschiedene Strategien ausprobieren, wenn man erkennt, dass der Anwendungs-I/O einen „Logjam“ auf seinem Weg zum Storage erfährt. Dieser Weg ist eine Kombination aus Software (APIs, Kommandosprachen und Protokolle) und Hardware (HBAs, Kabel, Switch-Ports und Geräteverbindungen), der die Applikation mit den gespeicherten Daten verknüpft. Ein einfacher Indikator für ein Problem auf diesem Pfad ist eine größer werdende I/O Queue, das heißt, dass viele Schreib-Operationen darauf warten, auf das Storage geschrieben zu werden.

Ich habe die Erfahrung in Anwenderumgebungen und unseren Labs gemacht, dass die Warteliste der Writes bei VM-Performance-Problemen ziemlich kurz ist. In anderen Worten: Das Problem der langsamen VMs kann logischerweise nicht den Storage-Latenzen zugeschrieben werden. 

In den meisten dieser Situationen findet sich zeitgleich eine extrem hohe Rate an Prozessorenlast auf den Servern, die diese VMs hosten. Wenn die Prozessoren heiß laufen, weist dies oft auf ein Problem in der Applikation oder in der Hypervisor-Software hin. Das bedeutet, dass der „Logjam“ oberhalb des Storage-I/O-Layers liegt.

Der Hypervisor kann der Flaschenhals sein

Das böse, herkömmliche, proprietäre Storage könnte also gar nicht der Verursacher der langsamen VMs sein. Es ist eher möglich, dass die virtualisierte Anwendung oder der Hypervisor das Problem ist. 

Das wirft die Frage auf, warum das existierende Storage entfernt werden soll – in den meisten Fällen eine Infrastruktur, in die viel Energie und Geld gesteckt wurde, um zum Beispiel ein SAN zu installieren oder NAS-Fileserver ins Netzwerk zu integrieren. Und dies soll nun durch DAS-JBODs ersetzt werden, die mit dem aktuellen Software-Controller-Kit des Hypervisor-Herstellers operieren.

Der so genannte „I/O-Blender-Effekt“ (Vermischungseffekt) ist real. Verbindet man einige VMs und lässt diese einfach laufen, so vermischen sich viele Random-I/Os zu einem inkohärenten Durcheinander an Schreibprozessen, die in kurzer Zeit die Flash-Ressourcen aufbrauchen und Festplattenplatz belegen, was wiederum zu langsamen VMs führt. 

Das ist per se kein Storage-Problem, aber eines der Hypervisor-Strategie. Nehmen wir an, Sie wollen ihren Hypervisor weiterhin einsetzen, so sollten Sie einen effizienteren Weg finden, Daten zu organisieren und zu schreiben. Dafür lassen sich zum Beispiel der Log-strukturierende Ansatz von Firmen wie StarWind Software nutzen oder ein effizienter Software-Controller von PernixData oder ein übergreifender Controller von DataCore – in all diesen Fällen müssen Sie ihre zugrunde liegende Storage-Hardware-Infrastruktur nicht ändern.

Ob Sie nun ihr existierendes Storage gegen einen Server-seitigen Ansatz austauschen, liegt ganz bei Ihnen. Allerdings sollten Sie genau wissen, warum Sie dies tun. 

Meine Recherchen belegen, dass ein Austausch von herkömmlichen Storage gegen DAS nicht das Problem langsamer VMs adressiert. Vielmehr sollten Sie zunächst einfache Messungen durchführen, um die Prozessoraktivität und die Queue zu überprüfen, bevor Sie sich für eine neue Strategie entscheiden.

Folgen Sie SearchStorage.de auch auf Twitter, Google+ und Facebook!

Artikel wurde zuletzt im April 2015 aktualisiert

Pro+

Premium-Inhalte

Weitere Pro+ Premium-Inhalte und andere Mitglieder-Angebote, finden Sie hier.

Erfahren Sie mehr über Datenspeicherlösungen für virtuelle Server

Diskussion starten

Schicken Sie mir eine Nachricht bei Kommentaren anderer Mitglieder.

Mit dem Absenden dieser Daten erklären Sie sich bereit, E-Mails von TechTarget und seinen Partnern zu erhalten. Wenn Ihr Wohnsitz außerhalb der Vereinigten Staaten ist, geben Sie uns hiermit Ihre Erlaubnis, Ihre persönlichen Daten zu übertragen und in den Vereinigten Staaten zu verarbeiten. Datenschutz

Bitte erstellen Sie einen Usernamen, um einen Kommentar abzugeben.

- GOOGLE-ANZEIGEN

SearchSecurity.de

SearchNetworking.de

SearchEnterpriseSoftware.de

SearchDataCenter.de

Close