Synchronously Mirrored Storage – The right place for Flash?

Based on the number of environments I’ve seen in the last couple of months, I can definitely confirm that the DACH region and especially Germany is still the land of synchronously mirrored storage systems.

While this kind of design offers a couple of valid advantages, it on the same time introduces a couple of challenges. In my option the biggest challenge is the price tag that comes with a synchronously mirrored storage.

In the end you have to pay not only for the virtualization layer and its features that runs on top of the actual storage, but also for twice the number of controllers, spinning disks and Flash devices. Not to speak of other things like maintenance, power & cooling, etc.

But there is another important factor I would like to cover in this post, the performance penalty.

Obviously nobody will go all-flash throughout the whole datacenter as nobody can really afford that. So the solution is to use a rather small fraction of Flash compared to the total storage capacity. And it actually doesn’t matter if we talk about a handful of Flash devices for existing arrays or All Flash Arrays, the problem is pretty much the same.

There will always be a gap between the individual device performance and the net performance the storage system is able to deliver. This could have multiple reasons like limited CPU performance, data services, RAID overhead, etc. Let’s take a closer look at it in the scenario of a synchronously mirrored storage.

StrechedClusterAssumption: 25k writes & 75k reads per 800GB SSD.

The first performance loss comes into play when protecting the local SSDs with some form of RAID. Depending on the number of devices this is often a RAID1 or RAID10, rather rarely a RAID5. So you add like four SSDs to the local system and what do you get out of it? Just 50% of the performance & Flash capacity. So instead of getting 100k write IOPS you get like 50k and just 1.6TB of Flash capacity.

And it won’t get better, even if you add the exact same number of SSDs to the array at the other site, the usable capacity will still be just 1.6TB, simply because of the synchronous mirror.

When it comes to read performance, things look a bit better but the capacity is still just 1.6TB. Depending on the storage controller and storage virtualization layer the system is maybe able to read from multiple device simultaneously and can read independently on both sites to get some more IOPS out of the system.

But will you be able to really consume all those IOPS?

To be able to utilize all those IOPS it requires consumers in form of application that could request all those IOPS. But what happens when you move a 1TB database onto a Flash volume? The capacity is gone and you can think about what other workloads you could move onto the remaining space. But is it likely that those workloads really request all those IOPS? Probably not. So there is a bunch of IOPS left on the road that can’t be used by other applications.

Because of the costs for Flash in storage arrays, many companies consider using features like Auto-Tiering to use Flash within a bigger pool of storage. This way you could keep just the really hot data on Flash, so that every application could get a small piece of the cake. Sounds good at first. But do you know all of your apps good enough to know if the Auto-Tiering should consider only reads? Maybe writes? Or both? In which intervals will blocks be moved around? Are the blocks still hot when they got moved hours later? You probably get the point I’m making here. And let’s not forget those features are usually not free of charge at all.

Is there a way to do it more efficiently?

Indeed there is one. What if you could get 200k write IOPS and 600k read IOPS and lowest latencies?StrechedClusterFVP

Using FVP as acceleration layer across multiple ESXi hosts that could leverage those SSD drives to scale-out the performance with every single device you add. This would give you about 6.4TB of Flash capacity for an acceleration at raw device performance to accelerate a wide range of applications.

The storage system wouldn’t be replaced in this design and would still provide the pooled SAS & SATA capacity, in conjunction with some other data services.

With FVP in the picture, there would be even an offloading of IOPS from the spinning disks up to the Flash devices within the hosts.

Another advantage of having the low latency devices as close to the applications as possible is that this will remove a couple of shared resources and obviously the distance between the virtual machine and the storage system.

I want to wrap up this post with a question: Is a synchronously mirrored storage, at the end of the line, the right place for Flash?

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