FVP


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


[DE] PernixData FVP – Fault Domains erklärt

Heute geht es um ein weiteres FVP Feature, die so genannten „Fault Domains“ (FD) und wo diese hilfreich bzw. ein Muss sind.

Wie in einem kürzlich aktualisierten Artikel beschrieben, ist die deutschsprachige Region noch immer bekannt dafür, verhältnismäßig häufig synchron gespiegelte Storage Systeme einzusetzen. Diesen Anforderungen muss FVP als Storage Performance Plattform natürlich entsprechend berücksichtigen.

Kommt mit FVP die Lesende- und Schreibende-Beschleunigung Beschleunigung zum Einsatz, so möchte man nicht nur sicherstellen, dass zusätzliche Kopien zwecks Fehlertoleranz geschrieben werden, sondern auch steuern, wo dies geschieht.

Mittels Fault Domains ist es möglich die eigenen physikalischen Gegebenheiten nachzubilden, um so Kontrolle darüber zu gewinnen, wo die zusätzlichen Kopien geschrieben werden. Dies ist also ein Muss, wenn es um die Kombination mit synchron gespielten Storage Systemen geht, vor allem dann, wenn dies Storage Systeme räumlich getrennt stehen.FVPwFD2

Noch ein paar Worte zu dem synchron gespiegelten Storage Systemen. Als Anforderungen aus Sicht von FVP, muss es sich bei dem darunterliegenden Storage System um ein vMSC kompatibles System handeln, bei dem alle Datastores in beiden Rechenzentren zugreifbar und im Fehlerfall auch wirklich beschreibbar sein müssen. Ideale Beispiele dafür wären EMC VPLEX, IBM SVC, DataCore SANsymphony-V, welche alle einen nonuniform Zugriff ermöglichen, indem immer alle Datastores in beiden RZs beschreibbar sind (Active/Active). Eine Array basierte Replikation, welche im Fehlerfall ein manuelles Eingreifen wie z.B. das Mounten von Datastores erfordert, kann somit nicht mit FVP und der Schreibenden-Beschleunigung kombiniert werden.

Nun zur Konfiguration, hierzu sind nur wenige Schritte nötig. Zunächst begibt man sich auf den Configuration Tab eines FVP Clusters und dann zum Unterpunkt Fault Domains.FaultDomains

Über den Button Add Fault Domain legt man einfach eine neue Domäne an und fügt anschließend die gewünschten ESXi Hosts über das + hinzu. Dies wird einfach für das zweite Rechenzentrum wiederholt.

Abschließend klickt man auf das + bei den Targets. Damit teilt man der Software mit, dass die Hosts aus RZ1, mit denen in RZ2 kommunizieren sollen.

Konfiguriert man anschließend eine VM oder einen Datastore für den Write-Back Modus, so ist es jetzt bei der Auswahl der Peer Hosts möglich, die Anzahl der Kopien wie folgt zu definieren.ConfigureWBwFD

  • In same Fault Domain“ – Das bedeutet, dass die zusätzliche(n) Kopie(n) für die Fehlertoleranz nur innerhalb der gleichen Fault Domain, sprich Gruppe von Hosts im gleichen RZ, stattfindet und NICHT auch im andere RZ geschrieben wird.
  • In different Fault Domain(s)“ – Umgekehrt wird damit wird festgelegt, dass die Kopie(n) auf jeden Fall auf einem Host der jeweils anderen Fault Domain, sprich auf einem Host im jeweils anderen RZ, geschrieben werden müssen.

Tipp: Es ist auch eine Kombination machbar. Pro VM/Datastore lassen sich bis zu zwei zusätzliche Kopien definieren. somit darf es auch eine Kopie in der lokalen FD und zusätzlich eine in der zweiten FD geben.

Wenn die definierte Write Policy nicht erfüllt werden kann, weil beispielsweise die Netzwerkkommunikation gestört ist, so wechseln die VMs im schlimmsten Fall für den Zeitraum der Störung auf den Write-Through Modus, also die rein Lesende-Beschleunigung.

Was die Verwendung der Fault Domains angeht, so ist dies nicht limitiert auf ganze Rechenzentren, sondern kann auch dazu genutzt werden, um z.B. Blade Chassis übergreifend die Fehlertoleranz zu gewährleisten. Dies ist vor allem dann interessant, wenn man als Beschleunigungsmedium RAM einsetzt. Denn somit kann man dem flüchtigen Medium RAM ein höheres Maß an Fehlertoleranz verleihen, indem die geschriebenen Daten Blade Chassis oder Rack übergreifend repliziert werden. Oder man stellt so sicher, dass die Writes ein Rack oder Blade Chassis nicht verlassen, um so die Latenz ggf. gezielt optimieren zu können.


[DE] PernixData Architect Software 1.0 – Details zum Launch

Nach der Ankündigung im Sommer, während des Virtualization Field Day 5, ist es jetzt soweit, die neue „PernixData Architect Software“ erblickt offiziell das Licht der Welt und ist somit ab heute GA.

Man hat vielleicht PernixData bis dato nur mit der FVP Software und somit einer einzigen Lösung identifiziert. Es sei aber gesagt, dass es sich bei der Architect Software grundsätzlich um ein völlig eigenständiges Produkt handelt.

Natürlich gibt es zwischen den beiden Lösungen FVP & Architect eine entsprechende Integration und Synergien, auf die ich im Laufe der Zeit noch tiefer eingehen werde.

 

Zunächst mal die wichtigste Frage – Was ist PernixData Architect?

Bei der Architect Software handelt es sich um eine Lösung zum Storage Management. Soll heißen, dass hier VM und Storage Intelligenz vereint werden umso das Storage Design, Deployment und den Betrieb effizienter zu gestalten. Ziel ist es, auf VM Ebene völlig neue Einsichten in Sachen I/O Profil & Verhalten zu schaffen, dazu gleich mehr.

Dabei ist die Lösung komplett Hardware unabhängig, egal auf welcher Server & Storage Plattform eine virtuelle Maschine betrieben wird.

 

Das heißt jetzt was genau? Wo kann der Architect helfen?

Schauen wir doch mal etwas genauer hin. Storage ist nach wie vor ein forderndes Thema, vor allem, wenn man exakte Designs realisieren möchte, Troubleshooting betreiben muss oder einfach nur verstehen möchte, was einzelne Applikationen so tun.

Interessiert einem da die Welt aus Sicht des Storage Arrays als Ganzes oder einer einzelnen LUN? Eher weniger. Viel interessanter ist doch, was einzelne VMs und damit die darin laufenden Applikationen machen. Denn nur so kann man klassischen Problemen wie „Mein SQL Server ist langsam“ mit Präzision zu Leibe rücken. Interessant ist doch welches I/O Profile einzelne VMs (oder natürlich einer ganzen Infrastruktur) aufweisen und wie dieses sich auf die Performance auswirken.

Ich stelle einfach mal ein paar Gegenfragen und denke dann wird es langsam klar:

Wie viele Durchsatz? Wieviel IOPS, in welchen Intervallen? Bei wie viel Latenz? Welchen Einfluss hat das Lese- / Schreibverhältnis? In welchen Blockgrößen? Wie trägt die Blockgröße zur Performance/Latenz der VM bei? Welche I/O Eigenschaften weißt die eigene Infrastruktur auf und welche Anforderungen stellt diese somit an die Storage Infrastruktur?

Der bisherige Ansatz wäre die Daten verschiedener Tools und verschiedener Stellen zu sammeln, sofern diese Verfügbar sind und sinnvoll zu korrelieren. Allzu oft scheitert dies auf Grund der fehlenden VM-Awareness, Tools, Zeit, etc.

Und genau hier setzt die Software an. All diese Fragen (und noch mehr) mit Leichtigkeit, individuell auf VM Ebene zu beantworten.ArchitectVMWorkloadArchitectVMWorkloadRWBlockSizeArchitectWorkloadOverview

Einzelne Features werde ich in einer Serie kurzer Blog Post individuell beschreiben.

 

Woher kommen die Daten?

FVP als auch Architect basieren auf der gleichen Host Extension (VIB Modul) und somit ist es möglich, die Messpunkte & Informationen direkt aus dem I/O Pfad der einzelnen virtuellen Maschinen zu sammeln.

In diesem Zusammenhang kann man sagen, dass eine Art Big Data Analyse auf dem Management Sever betrieben wird, damit man die Fülle an Informationen in ein userfreundliches und konsumierbares Format bringt. D.h. während das Herzstück von FVP direkt im Host lebt, so kann man sagen, lebt der Architect im Management Server (welcher der gleiche wie bei FVP ist) um dort die Verarbeitung und die Visualisierung vorzunehmen.

 

Welchen langfristigere Nutzen gibt es?

Hier sei gesagt, dass es meines Erachtens nach drei wichtige Punkte gibt, warum Architect einen langfristigen Nutzen bietet:

  1. Ohne den Architect ist es umso schwerer im Betrieb Storage seitiges Troubleshooting zu betreiben und Fragen des Business wie z.B. „Warum dauert die Auswertung xy so lange“ schnell und präzise beantworten zu können.
  2. I/O Profile von Applikationen unterstehen ständigem Wandel durch Updates, Anpassungen der Applikation, Skalierung wie z.B. Anzahl der User etc. Somit variiert natürlich auch die Performance und es ist wichtig dies kontinuierlich auf den Prüfstand zu stellen und zu optimieren.
  3. Dies Führt mich zur „Recommendation Engine“. Diese überwacht das I/O Verhalten und die Performance der VMs und wenn es hier zu negativen Veränderungen kommt, zeigt diese die Lösung an und gibt entsprechend mögliche Ursachen & Lösungsvorschläge für deren Lösung vor.

ArchitectRecommendations

 

Wie komme man an die Architect Software?

Dies ist entsprechend leicht. Für FVP Bestandskunden genügt ein Upgrade von FVP 2.5 bzw. 3.0 auf 3.1 welches automatisch die Option zur Trial der Architect Software mitbringt und einfach via UI aktiviert werden kann. Interessenten müssen lediglich das neuste 3.1 Softwarepaket installieren und können dann individuell die Trial von FVP und/oder Architect aktivieren.

 

Was ist PernixData Architect (aus meiner Sicht) nicht?

Um gleich zu Beginn zu vermeiden, dass man die Lösung in die falsche Schublade steckt. Architect …

  • … ist kein Monitoring Tool im klassischen Sinne, um z.B. anzuzeigen ob etwas online oder offline ist
  • … nutzt daher auch nicht das Prinzip, Kacheln/Lichter grün oder rot leuchten zu lassen um Probleme anzuzeigen
  • … Ist kein reines Sizing Tool und kein Ersatz des vROPS, sondern komplementär dazu.
  • … nutzt aktuell keinerlei Performance Daten aus dem vCenter, sondern sammelt alle Daten aus der Host Extension

Synchronously Mirrored Storage – The right place for Flash? *Updated*

As SE responsible for the DACH region, I get in contact with quite a lot of different customers of all sizes and I for sure can confirm, that one thing absolutely stands out, which is the widespread of synchronously mirrored storage systems in this region.

While this type of design offers a couple of valid advantages, like high availability across “sites” (if done right), it serves most enterprises as the foundation of their Business Continuity strategy.

But at the same time it also introduces a couple of challenges, because it’s not just about the storage alone, it is also about proper networking, firewalling & routing, resource management etc. But that’s actually enough content to write a book about it, that’s why I’ll dive deeper into the storage side of things for now.

There are two big challenges associated with a such design on the storage side, performance and economics. As you can imagine, both are tightly coupled.

I admit there is no way to get around the storage virtualization layer, but I contend there is definitely room for more efficiency when it comes to the overall storage design.

No matter if going Hybrid or All-Flash, the costs on the underling hardware will double for sure (not to speak of other things like maintenance costs, power & cooling, etc.) but other areas like usable capacity or performance will not.

But is there a way to create a more efficient storage design?

Based on the feedback I get, I can also tell that that the area of the All-Flash-Datacenter is still in its early days, so a common practice is to choose a hybrid model with just a fraction of Flash compared to the total capacity. And it actually doesn’t matter if we talk about a handful of Flash devices or All-Flash-Arrays, the problem is pretty much the same.

There will always be a gap, between the summed performance the individual Flash devices added to a storage system and the net performance a storage system is able to deliver. There are various reasons for that, limited CPU resources, data services, RAID overhead for instance. And now we add even more overhead to the mix.

The first performance loss comes into play when protecting the local SSDs with some form of RAID in every site. Depending a couple of factors, like the type of array or the number of SSDs, often RAID10 is used over RAID5. So let’s get more precise. I’ll use 4 x 800GB Intel DC S3610 per site, for all of my examples.

StrechedCluster2

This not only results in a performance loss, but also in just 50% or 1.6TB useable flash capacity.

Assuming a 70/30 Read/Write ratio, that would be theoretical 134.000k IOPS on paper. This of course doesn’t say anything about the latency a VM might observe at the end of the day.

Now we add the second site and the storage virtualization layer and we are still at 1.6TB usable Flash capacity due to the mirroring. At this point the write performance won’t increase, depending on the storage virtualization layer and the distribution the workloads across sites, the read performance potentially could.

But certain workloads in form of a virtual machine can only run either in site A or in site B. So in essence, if the total Flash capacity is limited, so are the number of VMs which potentially could be spread across sites to squeeze more read IOPS out of the system.

There are many more factors that could impact the latency in a negative way:

  • Is there an automated Storage Tiering involved, so that parts of the workloads may get migrated to slower Tiers over time? How long will it take until a block will promoted back to Flash?
  • What impact will competing workloads have on each other when running on the same flash pool?
  • Which impact will a varying block size have on the overall performance?
  • What is the real work read/write ratio of those workloads?
  • How big is the workloads working set? Does really everything need to be placed on Flash?
  • What impact will the fabric have on the overall latency?
  • Is there a way to ensure data locality, so that reads don’t have to be issued across sites?

A lot of questions which all too often get answered by bigger boxes, just to make sure things turn out as expected.

STOP, yes of there is a more efficient way!

You could leverage the power of a decoupled storage design, which offers some impressive advantages compared to the drawbacks outlined above.

With PernixData FVP in the picture, any can leverage a true Scale-Out Architecture to move the Flash part a storage design as close as possible to the actual workloads, namely directly into the hypervisor. This cuts lots of corners and helps to overcome previous challenges and to use Flash resources more efficiently. Not to mention, FVP could also use Host memory instead of Flash devices, but let’s keep it simple for now.

StrechedClusterFVP2

How about 6.4 TB usable Flash capacity in the first place? This not only means to be able to accelerate way more workloads simultaneously, but also to achieve a better Performance Isolation by aligning storage with compute. With the 8 SSDs in my example, you could equip up to 8 physical hosts.

Distributing multiple Flash devices across multiple hosts, multiple CPUs, multiple controllers, etc. helps to eliminate more and more bottlenecks compared to a central shared system. And especially removes some headaches around multipathing and helps to ensure data locality within a given host.

In terms of Performance this now means that for the first time any can get close to the summed performance of the individual Flash devices. Given the SSDs linked above, this could be easily in the range of hundreds of thousand IOPS. But IOPS are not really interesting, it all about the latency a VM (application) experiences.

A server side layer also offers more choices to its users when it comes to choosing an acceleration resource. Here any can leverage latest technologies. Assume we would replace the Intel DC S3610 with an Intel DC P3600 NVMe Flash device? Of course the price tag might be a bit higher the one of the SSD, but so is the performance by every means. This is also crucial if you want to design a modern storage platform with varying block sizes in mind! This approach allows to select appropriate types of media even for challenging workloads. By the way, to figure out the actual workload behavior, to be able to make those decisions in the first place, you could simply leverage PernixData Architect.

Due to the off-loading effect FVP has on the backing storage system, no matter if mirrored of not, this also allows for a more efficient backend design by potentially leveraging more capacity oriented RAID levels. This can further reduce the number of disks with all the benefits that come along with it.

Now it’s you turn to re-think your or your customer’s future storage design!