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

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. Dies bedeutet, dass FVP zusätzlich zur der lokalen Kopie des Blocks bis zu zwei weitere Kopien des gleichen Blocks synchron an einen bzw. zwei Peer Hosts innerhalb des Clusters sendet.4-replica1

Somit wird der VM der schreibende I/O erst 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.

Auch in diesem Fall, stehen alle geschriebenen Daten 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 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.

[DE] FVP – Die Grundlagen

Dies ist in der Tat mein erster Artikel in Deutsch und es fühlt sich zugegebenermaßen etwas fremd an. Da jedoch die FVP Gemeinde auch im deutschsprachigen Raum wächst und es natürlich auch Fragen zu FVP gibt, möchte ich die entsprechenden Antworten auf Deutsch geben. Die englischen Artikel von Frank Denneman sind hier zu finden.

FVP – Die Grundlagen

Mit diesem Artikel zum Wochenende möchte ich einen ersten Überblick geben, was FVP ist und natürlich in folgenden Posts auf einzelne Themen näher eingehen.

FVP als Softwarelösung hat ganz allgemein gesprochen das Ziel, virtuelle Maschinen bzw. deren Schreib- und Lese-Anforderungen zu beschleunigen und die Storage Performance von der Kapazität zu entkoppeln.

Um besser zu verstehen was FVP tut, hole ich kurz aus und erkläre kurz das Problem. Mit wachsender Anzahl an virtuellen Maschinen & Anwendungen, steigen stetig auch die Anforderungen an das zentrale Storage System. Es werden immer mehr IOPS & eine geringere Latenz benötigt damit Anwendungen in kürzester Zeit sind Daten zu verarbeiten.

Jedoch ist ein Hypervsior nicht dafür bekannt, Daten in einem für das Storage System freundlichen „Format“ zu schreiben. Allgemein ist das Problem als der „I/O Blender“ Effekt bekannt und beschreibt das Problem, dass durch das Scheduling des Hypervisors hauptsächlich zufällige Schreib- & Leseanforderungen Richtung Storage gesendet werden. Dies führt wiederum dazu, dass man entsprechend schnell an die physikalische Grenzen bzw. die maximale Leistungsmäßigkeit von HDDs stößt.

Hier kommt Flash als Medium sehr gelegen um dem Problem zu entgegnen. Über die Zeit haben sich viele Möglichkeiten entwickelt an verschiedensten Stellen der Infrastruktur Flash einzusetzen. Da Flash jedoch noch immer nicht zu den günstigsten Optionen zählt, ist ein möglichst effizierter Umgang mit möglichst hohem Kosten/Nutzen Verhältnis wünschenswert und genau hier setzt FVP an.

Die Software FVP besteht im Herzen aus einem Kernel Modul (VIB) welches sich direkt in den ESXi Hypervisor integriert. Dabei wird der Kern nicht modifiziert sondern allgemein zugängliche Schnittstellen genutzt. Damit ist der erste Punkt geklärt, wo FVP denn überhaupt sitzt, nämlich direkt im Hypervisor.

Um I/Os beschleunigen zu können, benötigt FVP natürlich auch entsprechend schnelle Medien in Form von Flash oder RAM. Ja auch RAM, dass sei an dieser Stelle nochmal explizit erwähnt, warum das wichtig ist erkläre ich in einem extra Post. Folgende Erklärungen lassen sich erst einmal gleichermaßen anwenden, unabhängig welches Medium man einsetzt. Diese Medien finden ihren Platz ebenso direkt um Hypervisor und werden dort von FVP verwaltet. Somit wäre der zweite Punkt geklärt, welche Medien FVP nutzen kann und wo diese stecken, im Hypervisor.

Jetzt gilt es noch beide Punkte zu kombinieren. Durch seine Position direkt im Hypervisor, ist FVP in der Lage Schreib- & Lese-Anforderungen von virtuellen Maschinen zu übernehmen und diese fehlertolerant auf die lokalen Medien schreiben bzw. entsprechend davon zu lesen.

FVP_GrundlagenWelche Vorteile ergeben sich daraus? Plötzlich haben VMs die Möglichkeit das Potential von SSDs, PCIe Flash Karten oder gar RAM zu nutzen. Sprich mehr IOPS, eine westlich geringere Latenz oder auch mehr Durchsatz.

Jetzt kommt noch ein wichtiger Punkt um den Basisteil abzurunden. FVP stellt keine Kapazität zur Verfügung. Dann stellt man sich natürlich die Frage, wo werden die Daten denn final gespeichert?

Die Antwort ist dabei recht simpel, auf genau dem gleichen Storage System wie bisher. Dieses kann in seiner aktuell Form genau so bestehen bleiben, völlig unabhängig des Herstellers und des verwendeten Storage Protokolls. FVP bildet ein Beschleunigungs-Schicht zwischen VMs und dem Storage System und kümmert sich entsprechend um das ordnungsgemäße wegschreiben der Daten.

Damit ist es erstmal möglich Performance und Kapazität zu entkoppeln und vor allem unabhängig voneinander zu skalieren.

FVP integriert sich transparent in virtuelle Umgebungen, was bedeutet das bestehende Umgebungen in ihrer Form nicht verändert werden müssen. Um die Erklärung abzukürzen, FVP unterstützt allgemein die Hardwarekomponenten die auf der VMware HCL zu finden sind. Daher ist FVP als Lösung auch komplementär zu bestehenden Umgebungen zu sehen welche durch die Software & entsprechende Medien direkt beschleunigt werden.

Die Lösung erfordert keinen RAID Schutz der lokalen Flash Devices, da die Fehlertoleranz anders sichergestellt wird, entsteht hier auch kein Verlust an IOPS oder nutzbarer Flash Kapazität für die Beschleunigung von VMs. Mit jedem zusätzlichen Device oder Host der Ressourcen in ein FVP Cluster beisteuert, steigt direkt auch die Leistung. Mal ein ganz einfaches Rechenbeispiel: Drei Hosts mit je einer durchschnittlichen Enterprise 400GB SSD und rund 30k IOPS, ergeben sich in Summe 90k IOPS und 1,2TB nutzbare Flash Kapazität um IOPS zu beschleunigen.

Wie angesprochen werden noch einige deutsche Artikel zum Thema FVP folgen in denen ich noch auf weitere Details eingehen werde.

 

PernixData FVP & linked-clones – The hidden gem

In this post I want to introduce you to a “hidden gem” in FVP that can help you to bring your VDI project on the fast lane. One piece to a successful VDI project is user acceptance and usability which is often tightly coupled to the responsiveness of a virtual desktop and its applications. This responsiveness in turn is defined by the time (measured in milliseconds) I/O operations of those virtual desktops take to complete.

I can remember some early discussions about read intensive VDI workloads but it turned out that VDI workloads are way more write intensive than expected. So to ensure an optimal user experience it’s important to accelerate not only reads but also writes in an efficient way.

Often the answer to this challenge is to add more spinning disks or expensive Flash to the existing storage infrastructure or setup a new silo in form of an All Flash Array or a hyper converged block respectively, just to run the VDI environment.

Using FVP an administrator has the choice between SSDs, PCIe Flash cards or even memory as server side media to speed up those latency sensitive I/O operations leveraging their existing storage infrastructure. This moves the performance directly into the hypervisor and decouples it from the storage capacity.

Sometimes the existing server hardware introduces some design constraints which limits the possible options of an acceleration media. For example blade servers usually can’t take advantage of PCIe Flash cards or VDI hosts often have a rather high memory utilization.

But especially for virtual desktops memory is actually an obvious choice for certain reasons like the ultra-low latency and a consistent performance whatever block size the VM is writing.

So let’s see if memory can be an option despite that fact that you may don’t have tons of memory left.

Linked clones are virtual machines whose virtual disks are linked to a so called “golden image” also known as “replica” which holds the actual operating system, including applications, corporate settings, etc. The golden image of course is read only, but Windows doesn’t work it can’t write to disk. So to fix that the linked clones can write their changes to individual virtual disks. Optimally both, the reads from the replica as well as the writes to the individual disks should be accelerated to ensure an optimal user experience.

That’s exactly what FVP is doing out of the box, there is no need to configure anything to achieve this. This of course includes support for VMware vMotion, VMware HA, etc.

But I would like to point out how efficient FVP deals with those linked clones. FVP out of the box recognizes linked clones and more important the base disk of the replica when accelerating the datastore which are storing those objects.

Instead of building an individual memory (or Flash) footprint for all the reads of every single virtual machine, FVP promotes just individuals blocks. So for example if VM A reads block Z from the replica disk (on the persistent storage) this particular block will be promoted to the FVP layer. If then VM B also reads block Z it is already there and can be served from the local acceleration media. FVP doesn’t promote the same block (from the replica) twice. So in essence, all linked clones can share the read cache content on a host. So you can see this linked-clone optimization as some form of de-duplication.

FVPandLinkedClones

Writes of every single VM will be accelerated individually as depicted above. Those individual written blocks on the local acceleration media can be used to directly serve subsequent reads.

As you can see on the screenshot below, the footprint of virtual desktops is rather low compared to the “Linked Clone Base Disk”. The allocated Megabyte of the linked clones are the individual writes.FVPLinkedCloneBaseDisk

This reduces the required amount of memory or Flash capacity to accelerate a whole lot of virtual desktops.

So let’s assume the thin provisioned size of the replica disk is 20GB and you have 100 virtual desktops per host, you only need 20GB of memory or Flash footprint to accelerate all reads of those desktops. These 20GB would be sufficient to virtually keep the whole golden image on the local acceleration media to speed up all VMs on a particular host.

Basically this applies to all non-persistent VDI deployments based on linked clone technology. No matter if VMware Horizon View or Citrix XenDesktp where FVP recently has been verified as Citrix XenDesktop ready.

With this hidden gem I would like to close not only this post but also the year 2014. I hope you’ve enjoyed it like I did, so have a great start and hopefully see you in 2015.