[DE] PernixData FVP – Lesende und schreibende Beschleunigung!


Nachdem ich mich jetzt etwas an das bloggen in Deutsch gewöhnt habe und ich mit Teil 1 die Grundlagen gelegt habe, denke ich können wir tiefer einsteigen.

Wie der Titel oder auch der letzte Post schon verraten hat, ist FVP in der Lage nicht nur gelesene, sondern auch geschriebene I/Os zu beschleunigen. Die Entscheidung wie beschleunigt werden soll, trifft der Nutzer über eine so genannte „Acceleration Policy“ und genau um diese Richtlinien geht es in diesem Post.

Zu Beginn sei erwähnt, dass sich folgende Richtlinien pro VM oder auch Datastore anwenden lassen. Das heißt, ein Nutzer kann granular für jede VM bzw. Anwendung entscheiden, ob und wie diese beschleunigt werden soll. Hat man sich dazu entschieden einen ganzen Datastore zu beschleunigen, ist es trotzdem möglich, einzelnen VMs auf dem bereits beschleunigten Datastore andere Richtlinien zuweisen. Ganz einfache Regel: VM Richtlinien überschreiben Datastore Richtlinien.

FVP_Conf_Accel_Policies_neu

Write-Through – Lesende Beschleunigung

Die denkbar einfachste Richtlinie legt fest, dass lediglich Leseanforderungen (Read I/Os) beschleunigt werden. Das bedeutet, dass wenn eine virtuelle Maschine Daten schreibt, diese direkt Richtung Storage gehen und das Ackownlegement des Storage Systems abgewartet werden muss. Somit ist die Leistung bzw. die Latenz für schreibende I/Os nach wie vor fest an die Leistungsfähigkeit des Storage Systems und des Transportwegs gekoppelt.

FVP sorgt an dieser Stelle vor und erstellt eine Kopie der geschriebenen I/Os und schreibt diese trotzdem auf das lokale Beschleunigungsmedium. So stehen die Daten für zukünftige Leseanforderungen direkt im lokalen Flash oder RAM zur Verfügungen und können von dort entsprechend schnell beantworten werden.

WT3 Daten die zum ersten Mal vom Storage System gelesen werden müssen, werden durch FVP an die VM geliefert und zusätzlich in Form eines so genannten „False Write“ oder „First Read“ auf das lokale Beschleunigungsmedium geschrieben um für zukünftige Leseanforderungen schnell zur Verfügung zu stehen.

WT_FalseWritesGenerell bedeutet das, dass alle Leseanforderungen (Read I/Os) welche direkt aus den lokalen Medien beantwortet werden können, nicht den Weg zum zentralen Storage System nehmen müssen.

WT_LocalAccelerationAuch wenn bei Anwendung dieser Richtlinie am Ende nur Read I/Os direkt aus FVP beantwortet werden, tragen jedoch Lese- und Schreibanforderungen dazu bei, den lokalen Footprint in FVP und damit die Beschleunigungsrate kontinuierlich zu steigern.

Im Idealfall findet das gesamte „Working Set“ der virtuellen Maschine in den lokalen Medien Platz, was zu einer hundertprozentigen Beschleunigung der Leseanforderungen führen würde und einer enormen Entlastung des zentralen Storage Systems.

 

Write-Back – Lesende UND schreibende Beschleunigung

Entscheidet man sich für diese Richtlinie, so werden entsprechend auch Schreibanforderungen (Write I/Os) beschleunigt. Dabei werden die Daten direkt auf das lokale Beschleunigungsmedium geschrieben und dann erhält die VM direkt eine Bestätigung für das erfolgreiche schreiben des I/Os.

WB0_neu

FVP kümmert sich dann etwas zeitversetzt um das wegschreiben der Daten auf das eigentliche Storage System, zur permanenten Speicherung der Daten.

Diese würde aber bedeutet, dass es zu diesem Zeitpunkt keine Fehlertoleranz gibt. Diese Richtlinie trägt den Namen „Write Back + 0“ und heißt nichts anderes, dass die geschriebenen Daten nicht auf zusätzliche Hosts repliziert werden. Es mag durchaus Szenarien geben, wie beispielsweise non-persistent VDI, wo dies durchaus sinnvoll sein kann. Denn dann operiert die VM mit der Schreibperformance des lokalen Mediums ohne Einflüsse durch den Transportweg, sprich das Netzwerk.

Grundsätzlich jedoch möchte man seine Daten immer bestmöglich geschützt wissen, sodass auch der Ausfall eines Hosts oder des Beschleunigungsmediums abgedeckt ist.

Und dies ermöglicht FVP wenn man sich für die Verwendung der Richtlinie „Write Back +1“ oder „Write Back + 2“ entscheidet. Das bedeutet, dass FVP zusätzlich zur der lokalen „original“ Version des Blocks, bis zu zwei weitere Kopien des gleichen Blocks synchron an einen bzw. zwei so genannte Peer Hosts innerhalb des Clusters sendet.

WB12Somit wird der VM der geschriebene I/O erst dann bestätigt, wenn alle Schreiboperationen auf allen beteiligten Hosts erfolgreich war. Somit ist sichergestellt, dass im Falle eines Hosts Ausfalls oder defekt des Beschleunigungsmedium, die Peer Hosts in der Lage sind, die noch nicht auf das Storage System geschriebenen Daten, ordnungsmäßig wegzuschreiben. Dies ist ein enorm wichtiger Punkt, denn hierzu ist kein manueller Eingriff des Nutzers notwendig. FVP stellt nach einem Ausfall sicher, dass ein Peer Host automatisch die Daten wegschreibt.

Natürlich stehen auch in diesem Fall, alle geschriebenen Daten direkt für zukünftige Leseanforderung zur Verfügung, dazu müssen diese nicht erst erneut vom Storage System gelesen werden.

Ein großer Vorteil dieser Richtlinie ist, dass sich jetzt die Latenz bzw. auch der mögliche Durchsatz bzw. die IOPS für die virtuellen maßgeblich nach Leistungsfähigkeit der verwendeten Beschleunigungsmedien richtet.

Bei allen Write-Back Richtlinien, werden die Daten zeitversetzt immer auf das zentrale Storage System weggeschrieben. Dieser Weg hat an dieser Stelle jedoch keinen Einfluss mehr auf die Latenz der VMs bzw. deren Anwendung. Somit können mittels FVP auch große IO Peaks komplett abgefangen und kontrolliert wegschreiben werden. Somit wird das zentrale System nicht mehr mit unkontrollierten Peaks belastet, welche sich wiederum negativ auf die virtuellen Maschinen auswirkt. Umkehret federt FVP Latenzspitzen seitens des Storage Systems ab, egal woher diese kommen mögen, ohne das die virtuellen Maschinen davon beeinflusst werden.

Der folgende Screenshot zeigt den FVP „Entkoppelungs-Effekt“ anhand der Latenz einer eines ganzen vSphere Clusters.

FVP_SAN_vs_VM_Latency_neu

Der Mehrwehrt an dieser Stelle ist sehr vielfältig. Dies kann beispielsweise helfen, wenn bestehende Storage Systeme am Rande ihrer Leistungsfähigkeit laufen und Anwendungen unter der schlechten Latenz leiden. FVP ermöglicht aber auch ganz neue Möglichkeiten beim Design neuer Storage Systeme.

Abschließend sollte noch erwähnt werden, dass selbst bei der Anwendung der Write-Back Richtlinie, vSphere Funktionalitäten wie vMotion oder auch VMware HA, DRS, etc. nach wie vor voll nutzbar und unterstützt sind. Dies ist nicht selbstverständlich und erfordert eine intelligente und geclusterte Lösung die in der Lage ist, die Daten zu jeder Zeit zu schützen, unabhängig von Ausfällen oder davon wie sich VMs innerhalb eines Cluster bewegen.

 

Wie werden die Daten zwischen den Hosts übertragen?

Dazu gibt es jetzt einen dedizierten Postm mit allem Wissenswerten rund um das Thema Netzwerk.

Wer sich jetzt noch frägt, wie man sicherstellen kann, dass Daten z.B. RZ übergreifend Repliziert werden können um beispielsweise vSphere Metro Storage Cluster zu unterstützen, der soltle einen Blick auf die Fault Domains werfen.

Print Friendly

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 *