[DE] PernixData FVP – Cluster konfigurieren

Mit diesem Post möchte ich zeigen, wie man schnell & einfach man PernixData FVP konfiguriert denn dazu sind lediglich 3 Schritte nötig:

  1. FVP Cluster erstellen
  2. Beschleunigungsressourcen hinzufügen
  3. Virtuelle Maschinen für die Beschleunigung konfigurieren

Der Einstieg in die Konfiguration beginnt mit dem FVP Tab.FVPTab

Mit + Create legt man im ersten Schritt ein neues FVP Cluster an, vergibt einen Namen, wählt das Ziel vSphere Cluster und fügt optional noch eine Beschreibung an.

NoFVPClusters CreateFVPCluster Ein FVP Cluster ist letztlich ein logisches Konstrukt, welches die Beschleunigungsmedien, die zu beschleunigenden virtuellen Maschinen und deren entsprechende Beschleunigungsrichtlinie zusammenführt.  Es werden automatisch alle Hosts des vSphere Cluster dem FVP Cluster zugeordnet.

Wie bereits hier beschrieben, ist es grundsätzlich möglich, pro vSphere Cluster mehre solcher FVP Cluster zu erstellen und diese mit verschiedenen Medien wie z.B. RAM oder Flash zu konfigurieren. Dies erlaub es Workloads in Form von virtuellen Maschinen den geeigneten Medien zuzuweisen.

MultipleFVPClustersKlickt man entsprechend auf den Namen des Clusters, öffnet sich dessen Übersichtsseite, welche an dieser Stelle natürlich noch keine Konfiguration und folglich noch keine Daten enthält.FVPClusterOverviewPage

Über den Configuration Tab werden im zweiten Schritt die gewünschten Medien über den Punkt Add Acceleration Resources hinzugefügt. Hier werden entsprechend alle lokal im ESXi Host verbauten Ressourcen aufgelistet. In diesem Fall füge ich exemplarisch eine zu definierte Menge RAM, welche jeweils pro ESXi Host exklusiv reserviert wird, dem FVP Cluster hinzu.FVPClusterAddResourcesRAM

FVPClusterAccelerationResourcesOverviewRAM

Im dritten und letzten Schritt, müssen nur noch die zu beschleunigende VMs ausgewählt und deren Beschleunigungsrichtlinie zugewiesen werden. Dies geschieht über den Menüpunkt Datastores / VMs gefolgt von Add Datastore oder Add VMs.

Der folgende Screenshot zeigt exemplarisch das hinzufügen einer einzelnen VM.FVPClusterAddVMs

Fügt man einen Datastore hinzu, wendet FVP automatisch die ausgewählte Richtlinie auf alle virtuellen Maschinen an, welche Ihr Hauptverzeichnis inkl. .vmx Datei auf diesem Datastore gespeichert haben. Dies ist zum Beispiel im VDI Umfeld nützlich, wenn man sicherstellen möchte, dass automatisch alle neu provisionierten VMs beschleunigt werden.

Sowie die VM(s) hinzugefügt wurde, beginnt die Konfiguration. Die Spalte Write Policy gibt die konfigurierte Richtlinie an, während die Spalte Status die tatsächlich angewendete Richtlinie anzeigt.WritePolicyStatus

Sollte in beiden Spalten nicht die gleiche Richtlinie angezeigt werden, bedeutet das schlicht, das die gewünschte Richtlinie nicht angewendet werden konnte. Über das ? erhält man mehr Informationen zur Ursache.WritePolicyExplantion.Korrigiert man die Ursache, so wechselt der Status automatisiert in den gewünschten Zustand.WritePolicyStatusFixed

Den Menü Punk, oder besser gesagt das Feature Fault Domains, habe ich bereits hier genauer beschrieben. Daher gehe ich hier nicht genauer darauf ein.

Über den Punkt Advanced bieten sich darüber hinaus noch folgende Möglichkeiten:

  • Blacklist – VMs werden unter keinen Umständen beschleunigt und auch in der Architect Software zukünftig nicht mehr bei den Sizing Funktionalitäten berücksichtigt.
  • VADP – Ermöglicht es FVP mit dem Backup zu integrieren. Mehr dazu hier.
  • Network Configuration – Erlaubt es einen VMKernel Port zu definieren, über welchen die Daten zwischen den Hosts ausgetauscht werden. Alles Wissenswerte dazu, hier.

[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

[DE] PernixData FVP – Wissenswertes zum Thema Netzwerk

Dieses Mal geht es um das Thema Netzwerk und was man dazu wissen sollte.

Ganz allgemein nutzt FVP einen VMKernel Port pro ESXi Host, um die Daten zwischen den verschiedenen Hosts (aka. Peer Hosts) auszutauschen. Standardmäßig wird nach der Installation der VMKernel Port genutzt, welcher auch für vMotion Traffic aktiviert ist. Damit ist FVP quasi „out-of-the-box“ startklar, jedoch kann man an dieser Stelle grundsätzlich zwei Punkte festhalten:

  • Da FVP auf Netzwerkschnittstellen des Hypervisors zurückgreift, bieten sich hier alle Design- & Optimierungsmöglichkeiten, die der Hypervisor zur Verfügung stellt
  • FVP Traffic ist Storage Traffic und sollte entsprechend auch so behandelt werden, sprich ebenso abgeschottet betrieben werden wie klassischer NFS oder iSCSI Traffic

Netzwerk Anforderungen

Eine häufige gestellte Frage an der Stelle ist, welche Mindestanforderungen FVP an das Netzwerk stellt, denn schließlich werden die geschriebenen Daten zwecks Fehlertoleranz synchron auf zusätzliche Peer Hosts geschrieben. Dazu mehr hier.

Die einfache Antwort ist, es gibt keine Mindestanforderung. Das heißt, FVP lässt sich bereits mit 1GbE Netzwerken einsetzen und setzt damit keine hohe Einstiegshürde.

 

Adaptive Network Compression

Dahinter steht wie Antwort, weshalb bereits 1GbE Netzwerke mit FVP verwendet werden können.

Wenn FVP erkennt, dass der VMKernel Port welcher für die Datenübertragung konfiguriert wurde, über eine 1GbE vmnic kommuniziert, so wird automatisch der ausgehende Traffic ab einer Block Größe von >= 16KB komprimiert. Dabei geht es darum zwischen Overhead & Nutzen abzuwägend, weshalb diese Größe gewählt wurde. Möglich wird dies durch ein proprietäres Protokoll, welches für die Host zu Host Kommunikation verwendet wird. Da hier kein SCSI gesprochen wird, bieten sich hier Möglichkeiten Daten sehr effizient auszutauschen. Hier gibt eine entsprechende Metrik, welche den Einsparungseffekt darstellen kann.NetworkOffloadingSomit reduziert sich die Datenmenge die es zu Übertragen gilt und damit wird das limitierte 1GbE Netz entlastet. Bei 10GbE ist dieses Feature standardmäßig deaktiviert. Dazu findet man hier noch ein kleinen Test.

 

Performance Metriken

Natürlich bietet FVP auch die nötigen Performance Metriken, um die Leistungsfähigkeit des Netzwerks zu analysieren. Der folgende Graph zeigt exemplarisch, wieviel Latenz für einen fehlertoleranten Schreibvorgang durch einen kompletten Round Trip (Transportweg + Schreibvorgang auf Peer Host) hinzugefügt wird. Damit hat man stets die Möglichkeit die Latenz des Netzwerks zu verfolgen und ggf. weitere Optimierungen vorzunehmen.

VMNetworkLatency

 

FVP Netzwerk Konfiguration

Pro vSphere Cluster ist es möglich den VMKernel Port zu definieren, über welchen die Daten zwischen den Hosts übertragen werden. Generell nutzt FVP maximal eine (physikalische) vmnic zur Datenübertragung, d.h. auch wenn zum Zeitpunkt der Installation z.B. Multi NIC vMotion eingerichtet ist, nutzt FVP nur eine der vorhandenen Schnittstellen.NetworkConfigDas heißt hier bieten sich wie angesprochen, alle Optimierungsmöglichkeiten die der Hypervisor erlaubt. Im Folgenden dazu ein paar Empfehlungen. Wenn es pro vSphere Cluster mehrere FVP Cluster gibt, nutzen dann auch all das gleiche VMKernel Interface.

 

vSwitch Konfiguration

Jetzt bietet vSphere an der Stelle ja einige Möglichkeiten, wie die Port Gruppen bzw. VMKernel Ports den vmnics zugeordnet werden können. Hier würde ich die Empfehlung aufteilen in 1GbE und 10GbE+ Netzwerke.

1GbE vmnics

Hier ist meine Empfehlung wann immer möglich, dem VMKernel für FVP eine dedizierte vmnic zuordnen um hier wirklich die gesamte Bandbreite nutzen zu können. Andere vmnics können auf die Liste der Stand-by Adapter gesetzt werden um im Fehlerfall entsprechend auf eine andere vmnic zurückgreifen zu können.VMKactivevmnic

10GbE+ vmnics

Hier ist die Erfahrung, dass Kunden im Schnitt 2 (Blades) bis 4 (Rack) 10GbE Ports für die Netzwerkkonfiguration zur Verfügung haben. In beiden Szenarien ist es oft ausreichend, FVP zusammen mit anderen Verbrauchern aktiv auf einer vmnic zu betreiben. Das heißt, hier muss keine dedizierte 10GbE vmnic zur Verfügung gestellt werden. Wer diese Option für sich nutzen möchte oder besser gesagt kann, darf dies natürlich gerne tun.

Dazu gibt es noch weitere Möglichkeiten FVP Traffic logisch von anderen Workloads abzuschotten und so die Netzwerk Latenz zu verbessen:

  • Dediziertes Subnetz verwenden
  • Dediziertes VLAN um den Traffic logisch vom Rest des Netzwerks abzuschotten
  • Network IO Control (wenn vorhanden) für den Typ „Management Traffic“, die Shares unbedingt auf Hoch setzen, um ein ungewolltes ausbremsen zu vermeiden
  • Optional: Jumbo Frames (MTU 9000) aktivieren

Hier ein kleines Beispiel, wie sich die Abschottung des VMKernel Ports positiv auf die Netzwerklatenz auswirken kann.VMNetworkLatencyOptimized

 

Scale-Out Effekt

Zuletzt würde ich gerne noch auf den Scale-Out Effekt von FVP eingehen.

Herkömmlicherweise ist es eher ein Problem, wenn die Anzahl der Hosts wächst, da bei einem Storage System die Anzahl der Ziel Ports statisch ist und je mehr Initiatoren sich verbinden, sich alle Initiatoren die Ziel Ports und damit deren Bandbreite & IO-Queues teilen müssen.HosttoArrayRatioMit FVP besteht jedoch die Möglichkeit der horizontalen Skalierung (Scale-Out), sodass mit steigender Anzahl der Hosts auch die Anzahl an Netzwerk Ports bzw. Host zu Host Verbindungen steigt.HosttoHostMeshZwecks Einfachheit habe ich jetzt auf die Redundanz in der Abbildung verzichtet. Aber so wird der Vorteil deutlich, mehr Hosts bedeuten mehr Bandbreite, mehr Queues und natürlich mehr Fehlertoleranz. Denn wenn ein Host ausfallen sollte, stehen mehr potentielle Partner zur Verfügung um die Fehlertoleranz für den Write-Back Modus schneller wiederherzustellen.

Im Vergleich zum herkömmlichen Storage Traffic, bei dem alle IOs lesend wie schreibend zum Storage Array transportiert werden müssen, müssen im Fall von FVP primär die geschriebenen IOs zwecks Fehlertoleranz übertragen werden. Durch das Prinzip der „Data Locality“ wird sichergestellt, dass der Read Cache einer VM, immer lokal in dem Host liegt, in dem die VM auch aktiv läuft.

Was passiert nach einem vMotion? Die Antwort ist das Remote Flash Feature, dazu folgt jedoch ein extra Post.