[DE] PernixData FVP 3.5 und Architect 1.1 verfügbar

Diese Woche wurden die neuesten Updates für die Architect als auch für die FVP Software veröffentlicht, damit erhöht sich die FVP Versionsnummer auf 3.5 und die von Architect entsprechend auf 1.1.

 

PernixData Management Server als virtual Appliance

Die wohl wichtigste Neuerung betrifft beide Lösungen gleichermaßen, denn der PernixData Management Server ist ab sofort als virtual Appliance verfügbar. Somit entfällt die Anforderung an einen Windows Server samt SQL (Express) Datenbank. Dies Lösung kann von nun an noch bequemer und vor allem schneller installiert werden.

Einen direkten Migrationspfad der Windows basierten Variante auf die Linux Appliance, existiert derzeit noch nicht. Jedoch ist es grundsätzlich möglich, über ein paar manuelle Schritte, die bisherigen Performance Daten auf die Appliance zu migrieren.

In einem extra Post zeige ich, wie man die Appliance ausrollt und einrichtet.

 

FVP – Unterstützung für Raw Device Mappings (RDMs)

Mit diesem Update erhält FVP die Unterstützung für virtual als auch physical RDMs. Somit ist es zukünftig möglich, auch virtuelle Maschinen mit RDMs lesend (WT) sowie schreibend (WB) zu beschleunigen. Einzige Einschränkungen, die RDMs dürfen nicht gleichzeitig an mehrere VMs angehängt (Multi-Writer) sein.

  • Hin und wieder gibt es Use Cases, bei denen z.B. in-Guest iSCSI Disks verwendet werden, z.B. um innerhalb von VMs Tools wie SnapManager for Oracle zu verwenden. Somit bietet sich jetzt die Möglichkeit, diese weiterhin unter Verwendung von RDMs zu nutzen und parallel von der aktiven Beschleunigung durch FVP zu profitieren.

 

Architect – PDF Performance Reports & UI Optimierungen

Der recht kleine Versionssprung auf 1.1 deutet an, dass es sich hierbei um kleinere Optimierungen handelt. Wichtigste Neuerung, ist die Einführung von PDF Performance Reports. Diese erlauben viele Werte der Architect Software bequem als Report zu exportieren. Dabei ist der Start als auch Endzeitpunkt, also der zu exportierende Zeitraum, frei wählbar.Architect1.1CreatePerfReportArchitect1.1PerfReport

Zusätzlich gibt es noch ein paar Optimierungen am User Interface, welche das navigieren und analysieren noch weiter vereinfachen. Beispielsweise gibt es jetzt neue Breakdowns, in Form einer Read oder Write Analyse. Architect1.1Breakdowns

D.h. diese Breakdowns beinhalten automatisch alle Metriken welche für die Read oder Write Performance relevant sind.

BreakdownOverviewZusätzlich wird jetzt die Acceleration Rate für Read und Write I/Os gesondert dargestellt, was einen besseren Überblick gewährleistet. Denn sonst würde eine VM im Write-Through Modus, mit 0% Acceleration Rate für Write I/O, den Gesamtwert verfälschen.ReadWriteAccelRate

Neben weiteren kleineren Optimierungen, kann man jetzt vom VM Performance Plot aus, direkt zur jeweiligen VM navigieren und diese im Detail analysieren.

Architect1.1PerformancePlot

[DE] Rollout des PernixData Management Servers als virtual Appliance

Dieser Artikel beschreibt, wie einfach sich die PernixData virtual Appliance ausrollen und in Betrieb nehmen lässt. Die Appliance und der damit verbundene Management Server, ist die Grundlage zur Verwendung der FVP als auch Architect Software und in der Regel der erste Schritt bei einem Rollout der Softwarelösung.

Das folgende Video zeigt, wie die Appliance in rund 3 Minuten ausgerollt ist und für die finale Konfiguration zur Verfügung steht. Generell sollte dieser Prozess den meisten ohnehin bekannt sein, daher gehe ich hier nicht im Detail darauf ein.

Einzig eine Option gibt es währen des initialen Deployments des ova Templates zu beachten, die Größe (vCPU & RAM) der Appliance. Wie der Screenshot aus dem vSphere Client zeigt, benötig die kleinste Variante 2 vCPUs und 4 GB RAM. Die zu wählende Größe richtet sich nach der jeweiligen Größe der vSphere Umgebung (Anzahl Hosts & VMs).ApplianceconfigSize

Appliance Konfiguration & Größe der Umgebung RAM vCPUs
Tiny (1-5 Hosts oder 1-50 VMs) 4 GB 2
Small (6-100 Hosts oder 51-1000 VMs) 8 GB 4
Medium (101-400 Hosts oder 1001- VMs) 12 GB 8
Large (400 Hosts+ oder 4000 VMs+) 16 GB 16

Die VDMK ist dabei erst einmal in allen Varianten auf 100GB limitiert.

Nach erfolgreichem Rollout, ist die Appliance unter der angegeben IP Adresse per Browser erreichbar: https://<IP>/config

Die folgenden Schritte zeigen, was dann abschließend noch zu tun ist.

ApplianceEULA ApplianceFirstTimeLoginDefault Username: pernixdata

Default Passwort: pernixdataappliance

AppliancevCenterConnect

Der hier verwendete Benutzer muss über administrative Berechtigungen auf Ebene des vCenter verfügen. Generell ist es auch möglich, vor ab eine Custom Rolle anzulegen, welche nur über die nötigsten Berechtigungen verfügt. Hier verweise ich auf die Knowledgebase.

ApplianceNetworkSettings

Wer zukünftig die proaktiven Support Funktionalitäten von PernixPlus verwenden möchte, sollte sichergehen, dass die Appliance mit dem Internet (ggf. über Proxy) kommunizieren kann.

AppliancePassword ApplianceNTP

Jetzt kann ist es möglich, über den grünen Button die eigentliche PernixData UI anzusteuern, diese ist ebenfalls per Browser über https://<IP oder FQDN>:60002 erreichbar und führt nach dem Login zum PernixData Hub. Für den Login können die gleichen Benutzerkonten verwendet werden, wie auch für den Login in den vSphere Client, da die Appliance alle Login Anfragen an den vCenter Server weiterleitet und dieser letztlich über den Zugriff entscheidet.

PernixDataHub

[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