[DE] PernixData VFD5 Ankündigungen zusammengefasst

Am 24.06.2015 war PernixData erneut zu Gast auf dem „Virtualization Field Day 5“. Wie bereits bei den vorherigen Teilnahmen nutze Satyam Vaghani die Chance zu präsentieren, was Kunden in naher Zukunft von PernixData erwarten können. In diesem Post möchte ich die Ankündigungen kurz zusammenfassen ohne dabei zu sehr ins Detail zu gehen. Dazu werden entsprechende Posts noch folgen.

 

PernixData Architect Software

Diese neue Software nimmt sich einem Problem an, welches bis Dato nur sehr schwer lösbar war.

Beispielsweise externe Planungs- und Monitoring-Lösungen. Diese setzten oft voraus statische Schwellwerte zu definieren um entsprechend Alarme auslösen zu können oder Entscheidungen zu treffen. Setzt man diese falsch, so ist natürlich alles was darauf basiert nur bedingt hilfreich. Andere beobachten das Verhalten einer VM und alarmieren entsprechend bei Abweichungen. Und dann?

Genau hier geht die neue PernixData Architect Software einen neuen Weg. Durch eine Analyse jeden einzelnen I/Os werden ganz neue Einsichten in das I/O Profil einer virtuellen Umgebung möglich.

PernixData Architect setzt zum einen auf eine Real-Time Analyse inkl. konkreter Empfehlungen zur Optimierung individueller VMs, als auch auf Informationen die bei der langfristigen Planung neuer Infrastrukturen extrem wertvoll sind. Und das alles auf Basis gesammelter Informationen der eigenen Infrastruktur unter Berücksichtigung, dass sich Workloads über ihren Lebenszyklus hinweg auch verändern können. Damit schließt sich der Kreis wenn es um das Design, das Deployment, den Betrieb und die Optimierung von virtuellen Infrastrukturen geht.architect-chartAn dieser Stelle würden ich gerne einfach ein paar Fragen in den Raum stellen, welche zukünftig mit der Architect Software beantwortet werden können:

  • Wie groß ist das Working-Set meiner virtuellen Maschine(n)?
  • Beziehungsweise wieviel Flash/RAM benötige ich für eine optimale VM Performance?
  • Wie sieht das Lese- Schreib-Verhältnis wirklich aus? 70/30 oder doch 50/50 oder wird gar mehr geschrieben als gelesen?
  • Mit welchen Block Größen arbeiten die unterschiedlichen VMs?

Damit erhält man erstmals die Möglichkeit & die Mittel um die Infrastruktur dahingehend zu planen oder zu optimieren um den betriebenen Anwendungen gerecht zu werden. Denn es besteht oft eine große Diskrepanz zwischen dem was man vermutet zu betreiben und dessen was die Applikationen wirklich tun oder benötigen. Architect1 Architect2

PernixData Cloud

Diese Komponente dreht sich maßgeblich um die Frage – “was Machen denn die anderen?”. Mit Hilfe einer Cloud basierten Engine, werden Metadaten anonym zentral ausgewertet um Kunden die Möglichkeit zu geben, die eigene Infrastruktur mit denen anderer Kunden bzw. anderer Kunden gleicher Größe zu vergleichen.

  • Welche Flash Devices kommen bevorzugt zum Einsatz?
  • Was sind die zu erwartenden Leistungsdaten der Flash Devices im Produkten Betrieb?
  • Nutzen andere bevorzugt EMC, HP oder Netapp Array?
  • Wie schlagen diese sich unter Produkten Bedingungen?
  • Liegt die eigene Infrastruktur im Trend oder gibt es gravierende Abweichungen?

cloud2 Cloud1

PernixData FVP Freedom

Mit FVP Freedom stellt PernixData eine kostenfreie Variante von FVP zur Verfügung die jeder in seiner Umgebung installieren & nutzen kann. FVP Freedom wird einige Einschränkungen im Vergleich zur regulären FVP Version enthalten:

  • Maximal 1 Cluster
  • 128GB RAM – Kein Flash
  • Ausschließlich lesende Beschleunigung
  • Community Support

Dafür gibt es keine Einschränkungen bezüglich der Anzahl von virtuellen Maschinen und Hosts!

Man stellt sich evtl. die Frage, was man bereits mit 128GB erreichen kann?

Um ein Beispiel zu nennen, was sich damit erreichen lässt, so konnte im VSImax Benchmark die Anzahl der User von 181 auf 328 (auf zwei Hosts) erhöht werden.

Wer möchte kann sich bereits jetzt registrieren: https://get.pernixdata.com/FVPFreedom

 

PernixData FVP

Last but not least, gab es natürlich auch einige Ankündigungen zu FVP selbst.

Die wohl auffälligste Neuerung ist dabei die neue (externe) Graphische Oberfläche basierend auf HTML5 & JavaScript die bereits auf den Screenshots oben zu erkennen ist. Diese macht es möglich Informationen nutzerfreundlich darzustellen und sich von technischen Limitierungen durch Plug-Ins zu lösen.

Des Weiteren wird die nächste Version von FVP vSphere 6.0 als auch vvols unterstützen. Hier wird die gewohnte Transparenz von FVP geboten, denn es gibt keinen erkennbaren Unterschied zwischen einer beschleunigten VM auf einem herkömmlichen Datastore oder auf einem vvol basierten Datastore.

Cloud Link nennt sich die neue integrierte Call Home Funktionalität um den Support noch weiter zu verbessern und pro-aktiv auf mögliche Probleme reagieren zu können.

 

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.