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

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 *