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

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 *