[DE] PernixData Architect – Drill-Down Charts


Hierbei handelt es sich um die deutsche Variante des Blog Artikel über das Feature „Drill-Down Charts“ der Architect Software.

Jeder kennt das Sprichwort, alle wege führen nach Rom und mit Architect, könntem an dies etwas umschreiben, denn dort führen alle Wege zu einer virtuellen Maschine. Aber warum ist das wichtig?

So ziemlich jeder, der im Bereich Virtualisierung & Storage arbeitet, kennt Sprüche wie “Der SQL Server ist langsam“. Im Normalfall ist dies der Anstoß für die Administratoren, nach den möglichen Ursachen in der darunterliegenden Infrastuktur zu suchen.

Ein Problem könnten natürlich CPU oder RAM Engpässe sein, doch wenn ein erster Blick auf die Auslastung jener Metriken dies nicht besätigt, dann ist Storage in der Regel der nächste Punkt den es zu prüfen gilt. Und die meisten wissen auch, das hier in der Regel das Problem  liegt.

Es kann natürlich viele Gründ geben, warum eine VM unter schelchter Storage Performance leidet. Eine mögliche Ursache sind Tasks die gerade auf dem Array laufen, wie ein RAID Rebuild zum Beispiel. Oder aber, eine andere VM erzeugt so viel Last, dass andere VMs darunter leiden, da die erzeugte Last die physichen Ressourcen des Transportwegs oder des Arrays selbst ausreizt. Es könnte aber auch kompletxere Ursachen haben, wie das sich beispielsweise das Workload Profil verändert und damit die vorhandene Infrastuktur anders beansprucht wird.

Betrachtet man sich in Folge dessen eine LUN auf Seiten des Storage Systems, so erhält man hier nur Array spezifische Informationen, ohne Informationen auf VM Ebene und ohne Einfluss des Transportwegs.

Mit der PernixData Archiect Software ist es jetzt möglich, solche Probleme auf VM Ebene zu anaylsieren und nachzuvollziehen.

Man könnte damit beginnen, die Machine über welche es Beschwerden gab, direkt zu anaylsieren, oder man macht ersteinmal einen Schritt zurück und betrachtet sich ersteinmal das gesamte Cluster.

Somit bekommt man den besseren Überblick und erkennt, ob es für das Cluster entsprechende Latenz-, IO- oder Durchsatzspitzen gegeben hat. Hat es diese geben, oder diese passieren aktuell noch immer, so kann man über das „Drill-Down“ Feature diese Spitzen ganz einfach analysieren, indem man einfach auf die jeweilige Spitze klickt.ArchitectVMObservedLatency

Dadurch öffnen sich ein Popup in der UI, welches die Top 10 VMs auflistet, welche beispielsweise die höchsten Latenzen aufweisen, oder aber die meisten IOPS bzw. Durchsatz erzeugt haben, abhängig davon, von welchem Chart man gerade kommt.DrillDownLatencyRW

Ein wichtiger Punkt dabei ist, das die Latenz-Spitze auf Cluster Ebene, die Daten aller VMs aggregiert repräsentiert. So lag dort die Latenz bei nur rund 20,6 ms. Auf VM Ebene analysiert, lag die Read Latenz der VM „DC01“ jedoch tatsächlich bei knapp 60ms. Fährt man mit der Maus auf den Latenzbalken, so zeigt sich sogar die Anzahl der betroffenen IOPS, welche mit dieser Latenz verarbeitet wurden.

Deshalb ist es so wichtig, Storage Analysen auf VM-Ebene durchzuführen, um genau zu verstehen mit welchen Problemen die einzelnen Applikationen in Form von VMs tatsächlich zu kämpfen haben.

Um zu überprüfen, dass keine andere VM das Storage System überlastet, kann man das gleiche Prinzip entsprechend auf den IOPS & Throughput Charts der Architect Software anwenden.

Mit diesen Charts und deren Drill-Down Möglichkeiten, ist es einfacher denn je, Storage bezogene VM Performance Probleme zu identifizieren.ArchitectThroughput1.1

Betrachtet man dann auch besagten Throughput Chart, zeigt sich zur gleichen Zeit in der auch die Latenzspitze auftrat, ein erhöhter Durchsatz. Dies könnte natürlich die Ursache für die erhöhte Latenz sein, aber liegt es tatsächlich nur am Durchsatz allgemein, oder hat sich möglicherweise noch andere Gründe? Die Antwort findet sich HIER.

Zuletzt noch ein Hinweis darauf, dass diese Drill-Down Möglichkeiten nicht nur auf Cluster Ebene zur Verfügung stehen, sondern auch wenn man einzelne VMs analysiert. So kann man beispielsweise während man die Read und Write Latenz einer virtuellen Maschine analysiert, direkt ein tiefgehender Blick in die Zusammensatzung der Spitze werfen. So erkennt man, ob die darunterliegende Infrastruktur Probleme hat, gewisse Block Größen zu verarbeiten. Und versteht somit auch erstmals, welche Block Größen eine VM tatsächlich erzeugt.DrillDownOnVMLevel

Print Friendly, PDF & Email

Related Post

It's only fair to share...Tweet about this on TwitterShare on LinkedInEmail this to someone

Leave a comment

Your email address will not be published. Required fields are marked *