[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?

[DE] Die Bedeutung von Latenz und Blockgrößen

Mit diesem Artikel möchte ich einen Überblick über das Thema Latenzen und Block Größen geben und was sich dahinter verbirgt. Nicht zuletzt auf Grund deren großer Einwirkung auf die Storage Performance von virtuellen Infrastrukturen.

 

Zum Start – Eine kurze Definition von Latenz

Einsteigen möchte ich mit der Latenz und was eigentlich dahintersteckt. Der Begriff ist sicher allen Leuten im Infrastrukturbereich bekannt und bezieht sich darauf, wie viel Zeit es benötigt eine Lese- oder Schreiboperation erfolgreich zu verarbeiten. Gemessen wird die Latenz in der Regel in Millisekunden (ms) und daraus lässt sich bereits ableiten, wie empfindlich das Thema ist.

Denn ob eine Datenbankoperation 6 Stunden oder nur 1,5 Stunden dauert, hängt davon ab, mit welcher Latenz die einzelnen Lese- oder Schreiboperation vom jeweiligen Speichersystem abgearbeitet werden.

Jetzt haben natürlich viele Faktoren in einem mehrschichtigen System, wie einer virtuellen Infrastruktur, einen direkten Einfluss auf die Latenz. Das beginnt bereits damit, ob es sich um eine Lese- oder Schreiboperation handelt und vor allem mit welcher Blockgröße diese auf die Reise geht. Dazu gleich mehr.

 

Lese- und Schreiboperation verhalten sich unterschiedlich

Im Vergleich zu einer einfachen Leseoperation, kann eine Schreiboperation eine enorme Last auf einem Speichersystem erzeugen. Zum einen dadurch, dass beim Schreiben auf ein RAID System ein höherer Overhead, auch bekannt als „Write Penalty“ entsteht.

Der Grund hierfür ist, dass aus einem einzelnen Write I/O, je nach RAID Level, ein Vielfaches an I/Os erzeugt wird, um diesen einzelnen I/O erfolgreich zu schreiben. Man trennt dies in der Regel nach Frontend I/Os, erzeugt durch die virtuellen Maschinen und Backend I/Os, den tatsächlich zu verarbeitenden I/Os auf. Nehmen wir ein RAID5 als Beispiel. So kann es sein, dass aus einem einzelnen Frontend I/O bis zu vier Backend I/Os entstehen. Dies teilt sich auf in zwei Leseoperationen, nämlich des Daten Blocks und des dazugehörigen Parity Blocks und beide müssen nach der Aktualisierung (Modify) wieder zurückgeschrieben werden.

Je her wird versucht dies durch einen nichtflüchtigen Cache (NVRAM) auf Seiten eines Speichersystems zu entgegnen. Was unter normalen Bedingungen auch oft funktioniert, wird dann spürbar wenn diese oft sehr limitierte Ressource an ihre Grenzen stößt, denn diese müssen sich viele Verbraucher (virtuelle Maschinen) teilen.

Dazu kommt, dass ein Großteil der I/Os einer virtuellen Infrastruktur als zufällige Zugriffe (Random I/O) am SAN ankommt und vor allem die Kapazität des Cache für Leseoperationen bei weitem nicht ausreichend ist, um die Anfragen schnell bedienen zu können. In den meisten Fällen, müssen die Daten von den Festplatten gelesen werden, was sich in einer sehr stark variierenden Latenz wiederspiegelt.

Somit hat auf das Lese-Schreibverhältnis einen nicht zu unterschätzenden Einfluss auf die Storage Performance.

 

Die Blockgröße – Die große Unbekannte

Was versteht man unter der Blockgröße?

Die Antwort relativ einfach. Die Blockgröße bezieht sich auf die Nutzlast (Datenmenge), welche in einer einzelnen Lese- oder Schreiboperation transportiert, respektive verarbeitet werden muss.BlockSizes

Ein 256K Block hat somit die 64-fache Nutzlast verglichen mit einem 4K Block. Entsprechend viel mehr Aufwand muss betrieben werden, um diese Daten zu verarbeiten.

 

Warum ist das wichtig?

Je mehr Daten transportiert werden müssen, desto mehr Ressourcen und nicht zuletzt Zeit wird benötigt, um die Operation in all den Schichten und Station zwischen dem Gastbetriebssystem und dem Speichersystem zu verarbeiten. Dabei hat der I/O viele Stationen zu nehmen, wie den ESXi Kernel, FC HBAs, Switches, Storage Controller, bis zur drehenden Festplatte. Und dabei ist der I/O selten alleine, sondern muss diese Stationen noch mit vielen anderen I/Os teilen. Dazu kommen noch Protokoll spezifische Einflüsse und wieviel Daten ein Cache bzw. eine I/O Queue überhaupt zeitgleich aufnehmen kann.

Wer annimmt mit Flash sei dieses Problem vom Tisch, den muss ich leider enttäuschen. Denn auch Flash kann empfindlich auf gewisse Schreiboperationen reagieren. Dazu zählen vor allem Schreiboperationen mit einer großen Blockgröße, welche auch bei modernen Flash Medien die Latenz oft enorm steigen lässt. Ein Grund ist die interne Daten Struktur von Flash. Im Falle einer Schreiboperation können die Daten nicht an Ort und Stelle überschrieben werden, sondern werden idr. gemeinsam mit anderen Daten in freie Regionen des Flash Medium geschrieben.

Das bedeutet in letzter Konsequenz, dass man erst die Workloads und deren Eigenschaften kennen muss, um auf Basis dieser Informationen entsprechende Design- und Optimierungs-Entscheidungen treffen zu können.

Nicht ohne Grund werden diese Informationen durch Storage Hersteller abgefragt, wenn es um die Planung eines neuen Systems geht. Leider werden hier allzu oft generische Werte ohne Bezug auf die eigene Infrastruktur und die eigenen Workloads verwendet.

Grund hierfür ist, dass diese Informationen bis dato nur sehr beschwerlich zu besorgen und auszuwerten sind. Einzig über CLI Tools wie z.B. vscsiStats ist es möglich diese Daten individuell für jede einzelne VMDK zu sammeln und im Nachgang auswerten. Was bei einer großen Anzahl von virtuellen Maschinen einen nicht zu stemmenden Aufwand bedeutet.

 

Was kann die Blockgröße beeinflussen?

Das ist in der Tat eine etwas unterschätze Frage, denn viele Prozesse können dazu führen, dass sich die Blockgröße verändert.

Das beginnt damit, dass ein Betriebssystem in der Lage ist, bereits in der virtuellen Maschine auf Ebene des Dateisystems, mehre kleinere Schreiboperationen zu einer großen zusammenzufassen.

Geht damit weiter, dass es oft auf Datenbank oder Applikationsebene Modifikationsmöglichkeiten gibt und endet damit, dass durch Updates von Applikationen und Betriebssystemen sich diese schlicht grundsätzlich ändern können.

Somit können bereits kleine Anpassungen und tägliche Operationen unbeabsichtigte Auswirkungen auf die Storage Performance nach sich ziehen. Wie variabel das sein kann, abhängig davon welche Prozesse gerade Daten verarbeiten, zeigt der folgende Screenshot einer VM analysiert durch die PernixData Architect Software.ArchitectWorkloadAnalyse

Welche Möglichkeiten es in der PernixData Architect Lösung noch gibt, um die hier besprochenen Punkte zu analysieren, erkläre ich in den folgenden Posts.

 

[DE] PernixData FVP – Cluster konfigurieren

Mit diesem Post möchte ich zeigen, wie man schnell & einfach man PernixData FVP konfiguriert denn dazu sind lediglich 3 Schritte nötig:

  1. FVP Cluster erstellen
  2. Beschleunigungsressourcen hinzufügen
  3. Virtuelle Maschinen für die Beschleunigung konfigurieren

Der Einstieg in die Konfiguration beginnt mit dem FVP Tab.FVPTab

Mit + Create legt man im ersten Schritt ein neues FVP Cluster an, vergibt einen Namen, wählt das Ziel vSphere Cluster und fügt optional noch eine Beschreibung an.

NoFVPClusters CreateFVPCluster Ein FVP Cluster ist letztlich ein logisches Konstrukt, welches die Beschleunigungsmedien, die zu beschleunigenden virtuellen Maschinen und deren entsprechende Beschleunigungsrichtlinie zusammenführt.  Es werden automatisch alle Hosts des vSphere Cluster dem FVP Cluster zugeordnet.

Wie bereits hier beschrieben, ist es grundsätzlich möglich, pro vSphere Cluster mehre solcher FVP Cluster zu erstellen und diese mit verschiedenen Medien wie z.B. RAM oder Flash zu konfigurieren. Dies erlaub es Workloads in Form von virtuellen Maschinen den geeigneten Medien zuzuweisen.

MultipleFVPClustersKlickt man entsprechend auf den Namen des Clusters, öffnet sich dessen Übersichtsseite, welche an dieser Stelle natürlich noch keine Konfiguration und folglich noch keine Daten enthält.FVPClusterOverviewPage

Über den Configuration Tab werden im zweiten Schritt die gewünschten Medien über den Punkt Add Acceleration Resources hinzugefügt. Hier werden entsprechend alle lokal im ESXi Host verbauten Ressourcen aufgelistet. In diesem Fall füge ich exemplarisch eine zu definierte Menge RAM, welche jeweils pro ESXi Host exklusiv reserviert wird, dem FVP Cluster hinzu.FVPClusterAddResourcesRAM

FVPClusterAccelerationResourcesOverviewRAM

Im dritten und letzten Schritt, müssen nur noch die zu beschleunigende VMs ausgewählt und deren Beschleunigungsrichtlinie zugewiesen werden. Dies geschieht über den Menüpunkt Datastores / VMs gefolgt von Add Datastore oder Add VMs.

Der folgende Screenshot zeigt exemplarisch das hinzufügen einer einzelnen VM.FVPClusterAddVMs

Fügt man einen Datastore hinzu, wendet FVP automatisch die ausgewählte Richtlinie auf alle virtuellen Maschinen an, welche Ihr Hauptverzeichnis inkl. .vmx Datei auf diesem Datastore gespeichert haben. Dies ist zum Beispiel im VDI Umfeld nützlich, wenn man sicherstellen möchte, dass automatisch alle neu provisionierten VMs beschleunigt werden.

Sowie die VM(s) hinzugefügt wurde, beginnt die Konfiguration. Die Spalte Write Policy gibt die konfigurierte Richtlinie an, während die Spalte Status die tatsächlich angewendete Richtlinie anzeigt.WritePolicyStatus

Sollte in beiden Spalten nicht die gleiche Richtlinie angezeigt werden, bedeutet das schlicht, das die gewünschte Richtlinie nicht angewendet werden konnte. Über das ? erhält man mehr Informationen zur Ursache.WritePolicyExplantion.Korrigiert man die Ursache, so wechselt der Status automatisiert in den gewünschten Zustand.WritePolicyStatusFixed

Den Menü Punk, oder besser gesagt das Feature Fault Domains, habe ich bereits hier genauer beschrieben. Daher gehe ich hier nicht genauer darauf ein.

Über den Punkt Advanced bieten sich darüber hinaus noch folgende Möglichkeiten:

  • Blacklist – VMs werden unter keinen Umständen beschleunigt und auch in der Architect Software zukünftig nicht mehr bei den Sizing Funktionalitäten berücksichtigt.
  • VADP – Ermöglicht es FVP mit dem Backup zu integrieren. Mehr dazu hier.
  • Network Configuration – Erlaubt es einen VMKernel Port zu definieren, über welchen die Daten zwischen den Hosts ausgetauscht werden. Alles Wissenswerte dazu, hier.