Notes from the field – S2D Performancebremse durch falsch konfigurierte NVMe Device | Hyper-V Server Blog

Notes from the field – S2D Performancebremse durch falsch konfigurierte NVMe Device

Vor kurzem hatte ich bei einer All-Flash Hyper-converged S2D Lösung beim Testen mit VMFleet "nur" 120.000 8k IOPs (70% Read - 30% Write). Das hört sich jetzt eigentlich nicht schlecht an, oder? Eigentlich nicht. Trotzdem war ich sehr verblüfft, weil ich fast die gleiche Werte bei einer wesentlich "schlechteren" Konfiguratation nur zwei Wochen vorher gemessen habe.

Hier die beiden Konfigurationen im groben Überblick:

All-Flash Konfiguration mit 4x Dell R730xd Knoten:

  • 2x E5-2699 22 Core CPUs
  • 768GB RAM
  • 2x 120GB Boot SSDs
  • 3x 3.2TB Samsung SM 1715 NVMe
  • 10x 1.9TB Samsung SM863 SSDs

"3-Tier" Konfiguratiaon mit 4x DataON S2D-3212:

  • 2x E5-2650 mit 14 Core
  • 512GB RAM
  • 2x 120GB Boot SSD
  • 2x 800GB Intel P3700 NVMe
  • 4x Intel S3610 800GB SSD
  • 8x 10GB HHD

Jetzt kann man natürlich einwenden, das VMFleet ja nur den Flash in einem "3-tier" S2D Design testet und damit die langsamen HDDs beim der Messung gar keine Rolle spielen. In der Default Konfiguration von VMFleet stimmt das auch. Ich hatte aber bei dem "3-tier" Design VMFleet so konfiguriert das über 50% der Testfiles auf den HDDs in einer double Parity Konfiguration lagen.

110.000 8k IOPs bei der "3-tier" Lösung sind unter diesen Umständen spitze! Nur 10.000 8k IOPs mehr in einer All-Flash Konfiguration -> DA STIMMT WAS NICHT!

Carsten Rachfahl
Cloud & Datacenter Management MVP

Was stimmte also in dieser Konfiguration nicht? Da ich in der VWFleet beim all-Flash Design eine sehr hohe Schreib-Latenz von über 200ms gemessen habe deutete das auf die NVMe Devices hin, da alle Writes erst mal in die NVMe gehen.

Die Lösung fand ich nach längerem Suchen im Device Manager! Es stellte sich heraus, das die NVMe Device unter der Sektion "Storage controllers" als "Standard NVM Express Controller" aufgeführt waren (siehe Screenshots).

Vor der Treiber Installation:

Nach der Treiber Installation:

*) Screenshot sind nicht aus der Kundenkonfiguration, sondern auf einem unserer S2D Cluster nachgestellt.

Nach der Treiber Installation ergaben sich folgende Verbesserungen:

  • Vervierfachung der 8k IOPs auf über 450.000 8k IOPs
  • Verringerung der Write Latenzen von über 200ms auf unter 30ms

Fazit: Die Installation der richtigen Treiber ist extrem Wichtig!

Mit diesen Werten (450.000 8k IOPs und Latenzen unter 30ms) ist meine Welt wieder in Ordnung! Als Fazit für mich: es ist nicht nur Wichtig, dass man die Performance einer Lösung messen kann, sondern es ist genauso Wichtig, dass man sie auch bewerten kann. Bewerten kann man aber leider nur, wenn man Vergleichswerte aus verschiedenen Implementierungen heranziehen kann.

Wer mehr zu Storage Spaces Direct wissen möchte findet vier Webinare in unserem kostenlosen Webinar Archiv.

Carsten Rachfahl
 

Dipl. Ing. Carsten Rachfahl ist seit mehr als 25 Jahren in der IT-Branche tätig. Er ist einer der geschäftsführenden Gesellschafter der Rachfahl IT-Solutions GmbH & Co. KG und für den technischen Bereich verantwortlich.

  • Dirk Richter sagt:

    Hallo Meister Rachfahl,

    eine kurze Frage dazu: Wie verhält sich das Cluster Shared Volume, wenn die Treiber aktualisiert werden. Sind die NVME dann noch Bestandteil des CSV oder muss das CSV bzw. S2D neu aufgebaut werden?

    Vielen Dank vorab

    Gruß Dirk

  • Carsten Rachfahl sagt:

    Hallo Dirk,

    habe schon erlebt das das ändern der Treiber von Microsoft auf Hersteller Treiber in einem PoC Cluster ein Bluescreen der Systeme ausgelöst hat. Du solltest also das austauschen der Treiber bei heruntergefahrener Workload durchführen (Wartungsfenster).

    Gruß Carsten

  • >