[DE] PernixData FVP – Ressourcenverwaltung


Mit diesem Post möchte ich einen Überblick geben, wie die Ressourcen Flash & RAM in FVP verwaltet und genutzt werden.

 

Hardware Anforderungen

Pro Host genügt bereits ein Flash Device um PernixData FVP einsetzen zu können, da in FVP die Fehlertoleranz der geschriebenen Daten über eine synchrone Replikation auf die Peer Hosts hergestellt wird. Mehr dazu finden Sie hier.

Somit bieten sich zwei Möglichkeiten um lokale SSDs zu konfigurieren. Eine RAID0 Konfiguration mit je einer oder mehreren SSDs oder alternativ können die SSDs direkt via HBA / Pass-Through-Mode an das Betriebssystem durchgereicht werden. Bei RAM sowohl als auch bei PCIe Flash Karten erübrigen sich diese Überlegungen, da hier in der Regel nur eine PCIe Karte pro host zum Einsatz kommt, bzw. pro Host nur einmal eine gewisse Menge RAM genutzt werden kann.

Generell müssen die für die Beschleunigung vorgesehenen Flash Devices (SSDs/PCIe Flash) für FVP exklusiv zur Verfügung stehen. D.h. eine Partitionierung um das Device noch anderweitig zu nutzen, wird nicht unterstützt.

 

FVP Cluster

Die Zuweisung von Flash oder RAM geschieht über die so genannten „FVP Cluster“. In diesem werden dann auch entsprechend die VMs, sowie deren „Acceleration Policy“ zugeordnet.

Für FVP sind die natürlichen Grenzen der vSphere Cluster und es ist nicht möglich ein FVP Cluster über diese Grenzen hinweg zu nutzen. Jedoch kann es natürlich mehrere solcher FVP Cluster geben, die Anzahl ist weder in Summe limitiert, noch gibt es ein Limit wie viele es pro vSphere Cluster geben kann. Das bedeutet, es ist möglich in einem vSphere Cluster gleich mehrere solcher FVP Cluster zu erstellen, um somit verschiedenste Medien wie z.B. RAM & Flash parallel zu nutzen. Allerdings ist anzumerken, dass RAM nur einmalig pro Host in einem Cluster genutzt werden kann.

MultipleFVPClustersEine virtuelle Maschine kann immer nur Mitglied eines FVP Clusters sein. Ein Tiering zwischen den verschiedenen Clustern/Medien findet nicht statt. So bietet sich aber die Möglichkeit, eine VM je nach Anforderungen oder IO-Profil einem geeigneten Medium zuzuweisen. Eine Migration von VMs zwischen den verschiedenen Clustern ist möglich, jedoch geht dabei deren aufgebauter Cache verloren.

Wird RAM als Beschleunigung Ressource genutzt, wird dieser Teil des Host RAMs exklusiv für FVP reserviert und steht dem ESXi Server selber für VMs nicht mehr zur Verfügung. VMware Admission Control wird durch diese neue RAM-Nutzung auch beeinflusst. Das Minimum sind 4 GB und das derzeitige Maximum liegt bei 1TB pro Host.

Bei Flash gibt es dagegen kein Minimum und das Maximum liegt bei derzeit 64TB, hier erweisen sich also eher die Erweiterungsmöglichkeiten des Servers als natürliche Grenze, denn dieser kann nicht unendlich Hardware aufnehmen.

Eine wenig genutzte Möglichkeit sind hybride Cluster, d.h. die Hosts sind nicht homogen ausgestattet und einige Hosts im jeweiligen FVP Cluster nutzen RAM andere wiederum Flash.  In der Regel wird pro FVP Cluster immer das gleiche Medium eingesetzt, mit der gleichen Kapazität pro Host.

Gibt es die Notwendigkeit mehrere SSDs pro Host zu nutzen ist es wichtig zu verstehen, dass eine virtuelle Maschine immer eine direkte Beziehung zu einer einzelnen SSD hat. Ist es gewünscht eine VM über die SSD Grenzen zu nutzen, z.B. Aufgrund eines größeren Working Sets, können die lokalen SSDs in einem RAID0 zusammenfasst und diese dem dafür vorgesehen FVP Cluster hinzufügt werden.

MultipleSSDsEin weiterer Vorteil der sich aus einer RAID0 Konfiguration ergibt ist eine Steigerung der Performance und die nicht mehr damit verbundene Limitierung auf die Performance einer einzelnen SSD.

 

Kapazität eines FVP Clusters

Ein nicht zu unterschätzender Punkt ist nutzbare Kapazität, welche sich mit FVP erzielen lässt. Generell gilt, dass die Kapazität aller eingesetzten Medien addiert werden kann und sich daraus die für die VMs zur Verfügung stehende Kapazität im FVP Cluster ergibt.

FVPClusterCapacityDer Großteil der Kapazität in einem FVP Cluster, respektive auf den lokalen Medien, entfällt im Normalfall auf den Read Cache der virtuellen Maschinen. Die Writes machen dagegen oft nur einen kleinen Teil aus und es sind dabei auch nur die Writes welche zu Zwecken der Fehlertoleranz auf weitere Hosts geschrieben werden müssen. Oft assoziiert man einen synchrone Writes direkt mit RAID1, sodass wenn eine Seite „vollgeschrieben“ ist, dies auch für die zweite gilt.

Bei FVP ist dies anders. Zum besseren Verständnis habe ich es aufgeteilt:

  1. Primärer Host: Auf diesem Host läuft die VM und hier werden die Writes auch nach erfolgreichem wegschreiben zum Storage System (destaging) weiter im Cache vorgehalten, sodass diese für zukünftige Reads zur Verfügung stehen.
  2. Peer Host(s): Hier können die Writes, welche auch Kapazität belegen, sofort wieder entfernt werden, sowie der primäre Host diese erfolgreich auf das Storage System geschrieben hat. Somit wird hier immer nur temporär Daten anderer Hosts vorgehalten. Die Menge variiert dabei mit dem jeweiligen Schreibverhalten der virtuellen Maschinen.

Der folgende Screenshot zeigt, dass es in diesem Fall nur 8,9GB sind, welche temporär gespeichert werden (eingehende Daten anderer Hosts). Je nach Schreibaufkommen können dies auch nur wenige MB sein.ResourceUsageLocalNetworkWenn die lokalen Ressourcen zu 100% gefüllt sind, müssen natürlicher Weise irgendwann Daten auch wieder entfernt werden (Eviction) um Platz für neue Daten (Population) zu schaffen. Dies geschieht über zwei Algorithmen.

 

Aufteilung der Ressourcen durch „Fair Share“

Ein Füllgrad von 100% ist natürlich wünschenswert, um so viele Daten wir möglich direkt im Host vorzuhalten um hohe Beschleunigungsraten zu erreichen. Selten wird pro Host nur eine VM beschleunigt, sondern im Normalfall mehrere VMs, welche sich die zur Verfügung gestellte Kapazität teilen müssen.LocalUsageHier kommt der FVP „Fair Share“ Algorithmus ins Spiel. Wenn die Anzahl der beschleunigten Maschinen steigt, bzw. die beschleunigten VMs mehr Platz anfragen, beginnt FVP damit die vorhandene Kapazität fair unter allen Verbrauchern aufzuteilen. Einfach gesagt, kann man die Kapazität durch die Anzahl an VMs teilen und erhält dann die Kapazität die einer einzelnen VM dann im „schlimmsten“ Fall maximal zusteht.

Diese Aufteilung, welche auch der nachfolgende Screenshot zeigt, passiert voll automatisiert durch FVP und erfordert keine manuelle Optimierung.FairshareInactionEine Möglichkeit VMs zu priorisieren gibt es derzeit nicht. Hier kann man jedoch darauf zurückgreifen, mehrere FVP Cluster zu erstellen, SSDs in mehrere Cluster zu konfigurieren und die VMs entsprechend aufzuteilen.

 

Intelligente Eviction von Daten

Im zweiten Schritt werden Daten auch aus dem Cache entfernt. Dies passiert immer intelligent auf VM Ebene und nicht willkürlich auf Ebene der Beschleunigungsmedien. Hier kommt ein entsprechender LRU Algorithmus zum Einsatz, welcher die Daten zuerst entfernt, welche länger nicht zugegriffen wurden.Population_vs_EvictionUm eine unnötige Verdrängung heißer Daten durch z.B. einen Datenbank Dump zu vermeiden, gibt es die Möglichkeit die Population via „Intelligent I/O Profiling“ zu kontrollieren.

 

Remote Flash – Was passiert nach einem vMotion?

Auch für dieses Scenario gibt es eine clevere Lösung. Anstelle den aufgebauten Cache Footprint zu löschen oder gar über das Netzwerk auf den ziel Host zu transportieren, nutzt FVP das so genannte „Remote Flash“ Feature. FVP erkennt auf dem Ziel Host, dass die VM gerade per vMotion migriert wurde und kann dann über das Netzwerk auf den Cache Footprint des Peer Hosts zugreifen. Dieser wird also nicht verworfen, sondern steht den VMs nach wie vor zur Verfügung. Der große Vorteil ist, dass die Daten nicht neu vom Storage System gelesen werden müssen und somit die Read Performance sehr konstant bleibt. Über Zeit baut sich die VM dann wieder einen neuen lokalen Footprint auf, um das Prinzip der „Data Locality“ wiederherzustellen. Wenn der Remote Flash Footprint über Zeit keine gültigen mehr Daten mehr hält, wird dieser verworfen.

RemoteFlash

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 *