[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


[DE] PernixData Architect – VM Performance Plot

Hierbei handelt es sich um die deutsche Variante des Blog Artikel über das Feature „VM Performance Plot“ der Architect Software.

Das wirklich Gute an den Architect Features generell ist, dass diese sehr einfach zu erklären sind und diese dennoch einen hohen Mehrwert bieten.

Viele Features sind im Normalfall mit konkreten Problemstellungen verbunden, zum Beispiel, wie identifiziert man am schnellsten VMs mit Performance Problemen? Oder solche die über die Maßen IOPS, respektive Durchsatz erzeugen?

Was in kleinen Umgebungen vielleicht noch machbar ist, wird mit zunehmender Anzahl von VMs zu einem ernsten Problem, welches mit viel Zeitaufwand verbunden sein kann. Und genau hier setzt die Architect Software an, im speziellen die Ansicht – VM Performance Plot.ArchitectStart

Nachdem man sich in die UI eingeloggt hat und über das Drop-Down Menü oben links in die Architect Software navigiert hat, bietet sich als Tab eben besagter VM Performance Plot.VMPerformancePlot

Jetzt stellt man sich evtl. die Frage, warum diese nicht wie alle anderen Informationen direkt innerhalb der jeweiligen Cluster zu finden ist? Die Antwort ist dabei recht einfach, denn der VM Performance Plot erlaubt, sich ein Bild über Cluster Grenzen hinweg zu verschaffen.

Als Nutzer ist man jetzt in der Lage, selbst die X- und Y-Achse definieren, wahlweise mit Latency, IOPS oder Throughput. Dann bietet sich die Möglichkeit den zu betrachtenden Zeitraum und zuletzt die vSphere Cluster auszuwählen.

Jetzt werden alle virtuellen Maschinen als Punkt repräsentiert. Fährt man mit der Maus auf einen Punkt, so erhält man mehr Einsichten zu den Performance Daten der VM, für den vorab ausgewählten Zeitraum.

Das hilft enorm, VMs zu identifizieren, die unter Performance Problemen leiden, wie beispielsweise hohe Latenz. Oder eben auch solche VMs zu erkennen, die unverhältnismäßig viel Last erzeugen.


[DE] Installation der PernixData Host Extension

Ein Punkt den ich bislang hier noch nicht im Detail beschrieben habe, ist die eigentliche Installation der PernixData Host Extension.

Die Host Extension, kommt in Form eines VIB Modules, welches den ESXi Host um die jeweiligen FVP & Architect Funktionalitäten ergänzt und bequem über zwei Methoden eingespielt werden kann.

Installation via esxcli (SSH)

Installation via Update Manager

Dazu habe ich jeweils ein Video vorbereitet, welche die Installation zeigt. Vor allem diejenigen, die bereits Treiber oder Patches über die beiden Verfahren installieren haben, wissen wie einfach dies geht. Wer darüber hinaus noch mehr Informationen und Details benötigt, der kann gerne einen Blick in die Installationsdokumentation werfen.


[DE] PernixData Architect – Einsichten in die Blockgröße

In meinem letzten Post über die PernixData Architect Software, habe ich über die so genannten Drill-Down Charts geschrieben. Am Ende ging ich nicht darauf ein, was diesen Latenzpeak verursacht haben könnte. Und genau darum geht es in diesem Post.

Es war eine Latenzspitze, als auch ein zunehmender Durchsatz zu erkennen, jedoch nicht mehr.

Mittels des “Block Size Breakdown” ist es möglich die Metriken wie Latenz, IOPS als auch den Durchsatz in die individuellen Blockgrößen aufzuschlüsseln um zu erkennen, wie diese die Storage Performance der virtuellen Maschine beeinflusst.ArchitectLatencyBlockSize

Wie gut zu erkenne ist, war die Latenz der VMs dadurch definiert, wie lange es dauerte Blöcke >=256k zu verarbeiten.

PernixData Architect kann nicht nur den Einfluss auf die Latenz darstellen, sondern auch herunterbrechen, wie viele I/Os in einer gewissen Blockgröße erzeugt wurden, respektive wieviel Durchsatz mit welcher Blockgröße erzeugt wurden.ArchitectIOPSBlockSize ArchitectMBsBlockSize

Wie bereits in vorangegeben Artikeln erwähnt, stehen all diese Informationen entweder aggregiert auf Cluster Ebene oder auch individuell auf VM Ebene verfügbar. Diese detaillierten Einsichten über die Blockgrößen die eine Umgebung oder eine VM erzeugt, können in vielerlei Hinsicht hilfreich sein.

Ist das vorhandene Speichersystem in der Lage das IO-Profil der VM(s) in adäquater Zeit zu verarbeiten? Also stellt das System genügend Bandbreite zur Verfügung, sodass das die Workloads nicht unnötig lange auf die Verarbeitung der Lese- und Schreiboperationen warten müssen?

Mit PernixData FVP im Blick, helfen diese Informationen das optimale Beschleunigungsmedium auszuwählen. Beispielsweise ist eine normale SATA SSD in ihrem Durchsatz alleine schon durch das SATA Interface limitiert. Wohingegen PCIe Flash Karten eine wesentlich größere Bandbreite bieten und natürlich nicht zuletzt RAM, welcher die höchste Bandbreite bietet. Mit diesen Medien wäre es möglich den erhöhten Durchsatz Bedarf der VM(s) in angemessener Zeit zu verarbeiten.

Und darüber hinaus, sind diese Daten enorm Hilfreich um in Diskussionen mit den jeweiligen Fachabteilungen zu treten. Müssen gewisse Workloads in einer für das System problematischen Blockgröße erzeugt werden, oder gibt es hier auf Seiten der Applikationen Optimierungsmöglichkeiten?