[DE] PernixData FVP – 2.5 steht in den Startlöchern

Gestern am 25. Februar hat PernixData das kommende FVP 2.5er Release angekündigt und natürlich möchte ich euch die neuen Features nicht vorenthalten.

 

DFTM-Z – Komprimierung für RAM

Nachdem mit FVP 2.0 die Beschleunigung mittels RAM, auch „Distributed Fault Tolerant Memory“ genannt, eingeführt wurde, so ist es jetzt möglich den verwendeten RAM beziehungsweise dessen Inhalt via LZ4 Algorithmus zu komprimieren.

RAM zählt nach wie vor zu den teuersten Beschleunigungsmedien (€/GB) und wird daher tendenziell mit geringerer Kapazität in FVP eingesetzt.

Um RAM auch bei geringerer Kapazität effizient einzusetzen, ist FVP nun in der Lage den Inhalt des Speichers zu komprimieren. Dies ermöglicht es, noch mehr Daten nahe an den virtuellen Maschinen vorzuhalten. Dies verbessert direkt das Verhältnis zwischen I/Os die aus FVP bedient werden können und denen die vom SAN beantwortet müssen (Hitrate).

DFTM-Z ist immer aktiviert, setzt aber erst ab einer konfigurierten Kapazität von 20GB RAM pro Host ein. 16GB von diesen 20GB werden als nicht komprimierter Speicherbereich genutzt, also wie bisher. Daten werden asynchron, also nicht während einer Schreiboperation, komprimiert und dem dedizierten 4GB Speicherbereich für komprimierte Daten zugeordnet. Lediglich wenn die Daten aus dem komprimierten Bereich gelesen werden, müssen diese direkt dekomprimiert werden.

FVP2.5MemoryCompression

Man kann sich vorstellen, dies ist wesentlich schneller, als Daten von einer drehenden Spindel aus dem Storage System lesen zu müssen. FVP allokiert maximal bis zu 32GB an RAM pro Host für den komprimierten Speicherbereich. Dies ist abhängig von der konfigurierten Kapazität des RAMs.

DTFM-Z_Table

Intelligent I/O Profiling

Hinter diesem Feature verbirgt sich die Möglichkeit für einen bestimmten Zeitraum, beispielsweise während eines Agenten basierten Backups innerhalb einer VM, die „Verschmutzung“ des FVP Footprint der betroffenen VM zu verhindern.

Ein kurzer Blick zurück auf die Beschleuigungs-Richtlinen zeigt, dass bei lesender als auch schreibender Beschleunigung Daten der VM auf das lokale Medium geschrieben werden. Das heißt, dass bei sequentiellen Workloads wie Virenscans, Backups oder Datenbank Dumps, so viele Daten auf das lokale Medium geschrieben werden, dass diese möglicherweise die eigentlich wichtigen (heiße) Daten verdrängen.

Das I/O Profiling lässt sich einfach mittels neuer PowerShell cmdlets pro VM aktivieren & wieder deaktivieren. Es ist möglich „False Writes“ als auch „True Writes“ für den gewünschten Zeitraum an FVP vorbeizuleiten.

  • Suspend-PrnxReadDataPopulation
  • Resume-PrnxReadDataPopulation
  • Suspend-PrnxWriteDataPopulation
  • Resume-PrnxWriteDataPopulation
  • Suspend-PrnxReadWriteDataPopulation
  • Resume-PrnxReadWriteDataPopulation

Wichtig ist jedoch, dass während dieser Zeit der aufgebaute Footprint der VM bestehen bleibt und I/Os weiterhin aktiv beschleunigt werden können.

 

RBAC – Rollen basierter Zugriff

Bislang konnte jeder User innerhalb des vSphere Clients nicht nur Performance Daten betrachten, sondern auch Konfigurationsänderungen in FVP vornehmen.

Die neuen Rollen basierten Zugriffe erlauben eine bessere Granularität und verbesserte Sicherheit in FVP. Grundsätzlich gibt es jetzt drei Modi:

  • Voller Zugriff: FVP Cluster Configuration, Usage, Performance Charts, Advanced Settings
  • Nur lesend: FVP Cluster Configuration ansehen, Usage sowie Performance Charts
  • Kein Zugriff
  • vCenter Administrator >> FVP voller Zugriff
  • vCenter Nicht-Admins >> FVP nur lesend
  • vCenter Kein Zugriff >> FVP kein Zugriff

FVP überprüft dabei die Berechtigungen auf vCenter Root-Level und Cluster Level.

Dieses Feature ermöglicht es auch nicht vSphere Administratoren wie beispielsweise Datenbank Administratoren einen sicheren Zugriff auf die Performance Graphen zu gewähren.

Der folgende Screenshot zeigt, dass Konfigurations-Optionen bei unzureichenden Berechtigungen entsprechend nicht verfügbar sind.

FVP2.5RBAC

 

Remote Flash für NFS

Remote Flash bedeutet, dass FVP nach einem vMotion Vorgang einer VM in der Lage ist, den zurückgelassenen Footprint weiterhin über das Netzwerk zu nutzen. Das heißt, FVP kopiert bei einem vMotion Vorgang den Footprint nicht, stattdessen erkennen wir, wenn eine VM Daten lesen möchte und leiten diese Anfrage an den Host weiter, von dem die VM kürzlich migriert wurde. Dies spart Bandbreite, Zeit und Flash Schreibzyklen.

Bislang war “Remote Flash” nur für Block Storage verfügbar, mit FVP 2.5 zieht arbeitet es jetzt Protokoll übergreifend, also auch mit NFS Storage.

[DE] PernixData FVP – Entkoppeltes Storage Design

In diesem Post geht um es zwei Punkte die sehr eng miteinander verbunden sind und meiner Meinung nach gemeinsam betrachtet werden müssen. Zum einen FVP im Kontext des Storage Designs kombiniert mit dem sog. Entkopplungs-Effekt.

Bisher war die Leistung einer virtuellen Maschine immer an die Leistungsfähigkeit des darunterliegenden Storage System gebunden. Sprich war das System in der Lage max. 5000 IOPS zu liefern, so konnten VMs auch nicht mehr abrufen. War dies doch der Fall, was bei stetig steigender Applikationsdichte schnell passiert, so steigen nicht die IOPS sondern leider nur die Latenzen. Das heißt, eine Anwendung muss auf Grund physikalischer Grenzen entsprechend länger warten bis die gestellten I/O Anfragen verarbeitet wurde.

Der folgende Screenshot zeigt dies ziemlich gut, denn man erkennt das die Latenz der VM mit der Linie der Datastore Latenz überlappt und quasi unzertrennlich ist.

VM_and_Datastore_Latency

Bis zu einem gewissen Punkt, an dem FVP aktiviert wurde. Dann nämlich passiert das entscheidende, die Entkoppelung. Durch die Tatsache, dass FVP lesende als auch schreibende I/O mittels Serverseitigen Medien wie Flash oder RAM beschleunigt, richtet sich die Leistungsfähigkeit jetzt primär nach dem Potential des eingesetzten Mediums. Die Leistung ist damit entkoppelt vom eigentlich Storage System und drehenden Spindeln. Das bedeutet abgekürzt, mehr IOPS, mehr Durchsatz bei wesentlich geringerer Latenz.

Wie auf dem Screenshot zu erkennen, trennen sich die bisher unzertrennlichen Linien. Die Latenz der VM sink unter 3 ms und ebenso die Latenz des Storage Systems sinkt, warum? Da ein Großteil der Anfragen durch FVP beantwortet werden kann und somit direkt das Storage System entlastet wird.

Zugegebenermaßen ist die hierdurch entstehende Latenz erst einmal relativ, denn für Kunde A sind Latenzen von 20ms völlig normal und ggf. auch tolerierbar für Kunde B jedoch eine mittlere Katastrophe. Auch hat nicht jeder Kunde Anforderungen von zehntausenden IOPS, also könnte man schlussfolgern, dass FVP hier nicht benötigt wird? Nein! Und das ist der Punkt um den sich dieser Artikel eigentlich dreht.

Der ein oder andere kennt das Problem wahrscheinlich, wie viele IOPS brauche ich oder mein Kunde eigentlich? Eine Frage deren Antwort wahrscheinlich ein paar Monate nachdem diese, falls überhaupt, beantwortet wurde, bereits durch neue Anforderungen hinfällig ist. Noch schwieriger ist die Frage beziehungsweise die Planung einer maximal tolerierbaren Latenz. Also was tun, möglichst viele HDDs? Flash im SAN? Wieviel Flash? Kombinieren mit Auto Tiering? RAID5 oder doch lieber RAID10?

Warum sich nicht den Enkopplungs-Effekt von FVP zu Nutze machen und diesen bei neuen Storage Designs miteinbeziehen?

Dieser Effekt ermöglicht plötzlich wesentlich mehr Spielraum beim Design neuer & innovativer Storage Lösungen. Muss das neue System wirklich mit Flash und HDDs überprovisionieren sein, um auf Lastspitzen und neue Anforderungen vorbereitet zu sein? Welche Mehrkosten entstehen alleine für eine Planung nach dem Motto „auf Nummer sicher gehen?“. All diese zusätzlichen HDDs erzeugen nicht nur initiale Kosten, sondern benötigen Rackspace, Strom & wollen nicht zuletzt auch gekühlt werden. Ist für eine kleine Umgebung evtl. ein Array bestückt mit SATA HDDs anstelle von SAS HDDs ausreichend? Muss es wirklich immer RAID10 sein um möglichst viele IOPS aus dem Storage System zu quetschen, oder kann ich möglicherweise kapazitätsorientiert RAID5 einsetzen?

Es geht nicht darum eine Finale Antwort zu liefern, sondern zum Überdenken anzuregen und Designs auf den Prüfstand zu stellen. Möglicherweise ergibt sich die Möglichkeit neue Wege zu beschreiten ohne dabei auf bewährte Technologien verzichten zu müssen.

[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 lesende sondern auch schreibende IOPS zu beschleunigen. Die Entscheidung wie beschleunigt werden soll, wird anhand einer sogenannten „Acceleration Policy“, im Folgenden einfach als Richtlinien bezeichnet, getroffen und genau um diese 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 User kann granular für jede VM bzw. Anwendung entscheiden, ob und wie diese beschleunigt werden soll. Hat man sich entschieden einen ganzen Datastore zu beschleunigen, kann man trotz allem einzelnen VMs auf diesem Datastore andere Richtlinien zuweisen, da dies einfach die Richtlinie des Datastore überschreibt.

 

Write Through – Lesende Beschleunigung

Die denkbar einfachste Richtlinie legt fest, dass lediglich lesende I/O Anforderungen beschleunigt werden. Das bedeutet nun, dass wenn eine VM Daten schreibt, diese direkt Richtung Storage gehen und das Ackownlegement des Storage Systems abgewartet werden muss.

1-wt

FVP sorgt an dieser Stelle vor und schreibt die Blöcke trotzdem auf das lokale Beschleunigungsmedium um zukünftige lesesende Anforderung direkt von Flash oder aus RAM beantworten zu können.

Somit ist die Leistung für schreibende I/Os im Sinne von IOPS & Latenz nach wie vor fest an die Leistung des SANs gebunden, wohingegen lesende I/Os aus FVP heraus voll von der Leistung von Flash oder RAM profitieren.

Lesende I/Os die entsprechend vom Storage System an die VM geliefert werden, werden in Form eines sogenannten „False Write“ auch direkt auf das lokale Beschleunigungsmedium geschrieben um für weitere Anforderungen schnell zur Verfügung zu stehen und damit nicht mehr vom Storage System geholt werden zu müssen.

2-fw

Auch wenn bei Anwendung dieser Richtlinie am Ende nur lesende Anfragen direkt aus FVP beantwortet werden, tragen jedoch schreibende sowie lesende I/Os dazu bei den lokalen Fußabdruck und damit die Menge an Daten die entsprechend beschleunigt ist, kontinuierlich zu erhöhen.

 

Write Back – Lesende UND schreibende Beschleunigung

Entscheidet man sich für diese Richtlinie, so werden entsprechend auch schreibende I/Os beschleunigt. Dabei werden die Daten direkt auf das lokale Beschleunigungsmedium geschrieben und dann der VM direkt ein Bestätigung für das erfolgreiche schreiben des Blocks mitgeteilt.

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 wie das die lokal geschriebenen Daten nicht auf zusätzliche Hosts repliziert werden. Es mag durchaus Szenarien geben, wie beispielsweise non-persitent VDI, wo dies Sinn macht.3-wb

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

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 zusätzlich zu dem lokal geschriebenen Block bis zu zwei weitere Kopien des gleichen Blocks synchron an einen bzw. zwei Peer Hosts innerhalb des Clusters repliziert.4-replica1

Somit wird der VM der schreibende I/O erst dann bestätigt, wenn alle Schreiboperationen auf allen beteiligten Hosts erfolgreich war. Somit ist sichergestellt, dass im Falle eines Host Ausfalls oder Defekt des Beschleunigungsmediums, die Peer Hosts in der Lage sind die noch nicht auf das Storage System geschriebenen Blöcke ordnungsmäßig wegzuschreiben.

Alle geschriebenen Daten stehen dann direkt für zukünftige lesende Anforderung aus FVP heraus zur Verfügung.

Ein riesen Vorteil dieser Richtlinie ist, dass die die Latenz bzw. auch die möglichen IOPS der VMs sich nicht mehr primär nach der Leistung des Storage Systems richten, sondern nach der Leistungsfähigkeit der verwendeten Beschleunigungsmedien.

Bei allen Write Back Richtlinien werden die Daten zeitversteht Richtung SAN weggeschrieben, da dies keinen Einfluss mehr auf die Latenz der VMs bzw. deren Anwendung hat. Somit kann FVP als Nebeneffekt auch große IO Peaks komplett abfangen und kontrolliert wegschreiben. Somit wird das SAN nicht mehr mit hohen Peaks belastet. Umkehret federt FVP Latenzspitzen seitens des SANs ab ohne das die virtuellen Maschinen davon beeinträchtigt werden.

Der folgende Screenshot zeigt die FVP in der Lage ist die Storage Leistung einer VM von der dahinterliegenden Storage Kapazität zu entkoppeln:

FVP_SAN_vs_VM_Latency

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

Der folgende Screenshot zeigt, wie die Konfiguration im vSphere Client aussieht.FVP_Conf_Accel_Policies

 

Wie werden die Daten übertragen?

FVP nutzt per Default das vMotion Netzwerk des vSphere Clusters zur Replizierung der Daten, da dieses in aller Regel in allen Umgebungen funktioniert. Natürlich ist es auch möglich eine eigene vmnic bzw. einen dedizierten VMKernel Port in einem eignen VLAN zuzuweisen. Dies kann bei Bedarf gleichzeitig für alle Hosts angepasst werden.

Dabei gibt es keine Mindestanforderungen an das Netzwerk, d.h. dies funktionier gleichermaßen mit 1GbE als auch 10GbE. Mit FVP 2.0 wurde eine Adaptive Netzwerk Komprimierung eingeführt die erkennt wenn der verwendete VMKernel auf 1GbE läuft und fortan mit minimalem Overhead die übertragenen Daten komprimiert.FVP_Conf_Network

 

Abschließend sollte noch erwähnt werden, dass selbst bei schreibender Beschleunigung 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 Lösung die versteht Daten immer zu schützen, unabhängig von Ausfällen oder davon wie sich VMs innerhalb eines Cluster bewegen.

 

Wer sich jetzt noch fragt, wie man sicherstellen kann, dass Daten z.B. RZ übergreifend Repliziert werden können um beispielsweise vSphere Metro Storage Cluster zu unterstützen, der muss sich bis zum nächsten Artikel über „Fault Domains“ gedulden.