none
SOFS Performance bei UNC Zugriff RRS feed

  • Frage

  • Hallo zusammen,

    ich entwickle gerade eine Konfiguration eines 2-Node SOFS als Basis für einen Hyper-V Cluster mit 4-5 Nodes.

    Die verwendeten Komponenten (Alle Windows 2012R2, bzw. HyperV Server 2012):

    SOFS-Nodes - 2x Proliant DL360G9 mit
    - 16 GB RAM
    - 2x 1Gbit NICs als Team für Management
    - 2x 10Gbit NICs für Storage - in zwei separaten Subnetzen auf zwei getrennten 10GE Switch
    - 16 Port LSI HBA je Host (9206-16e)
    - 3x Intel JBODs
    - Die Festplatten (keine SSDs - vorerst aus Budgetgründen)  im JBOD sind alles Seagate SAS HDs teilweise mit 7.2k, 10k und 15k. Für jede Klasse und dem Verwendungszweck entsprechend, wurden verschiedene Pools angelegt, und die Datenträger ebenfalls entsprechend. Die Columns bewegen sich zwischen 3 und 8. Enclosure-Awarness ist aktiviert (wurde zu Testzwecken aber auch schon mal deaktiviert, um höhere Columns zu erhalten).
    - MPIO ist aktiviert, aber eigentlich nicht nutzbar da sonst pro Host ein weiterer HBA notwendig wäre

    Hyper-V Nodes:
    verschiedene Modelle Proliant ML350G G8, DL360G9
    jeweils mit
    - 4x 1Gbit NIC als Team für Management und VM-Netz
    - 2x 10GE NIC für Storage


    Die NICs sind alle mit RSS konfiguriert, nur RDMA können sie nicht.

    Bei der Einrichtung des SOFS bin ich dem Artikel von Rachfahlt IT Solutions gefolgt.
    (http://blogs.technet.com/b/germany/archive/2014/07/10/die-installation-und-einrichtung-eines-scale-out-fileserver-unter-windows-server-2012-r2.aspx)


    Nun zur eigentlichen Frage, die mich schon etwas sturzig macht:

    Ohne das mich hier jemand belehrt: Ich weiß das ist keine Methode zur Performance-Messung, aber trotzdem habe ich aus neugierde nach der Installation natürlich versucht möglichst große Dateien quer durch den FS Cluster zu kopieren um mal 10GE und SMB Multichannel im Einsatz zu sehen. Natürlich werden Dateien gewählt, die größer als jegliche Caches sind.

    Kopieren zwischen den SOFS Nodes (auf deren lokale Platten) erreicht im Mittel an die 200 MB/s. Also der limitierende Faktor sind die lokalen Platten.

    Darauf hin habe ich die virtuellen Datenträger erstellt, und dem Cluster hinzugefügt.
    Einen CAP erstellt und die Freigaben dazu. Konfiguration wie im Artikel beschrieben.

    Dann sollte natürlich mal eine Test-VM zum laufen gebracht werden. Also habe ich eine auf meinem PC laufende VM per Explorer auf die SOFS Freigabe kopiert, und schon bin ich stutzig geworden:

    Ich habe nur zwischen 15 und 20 MB/s erreicht!

    Klar: ich habe nur eine Gbit Karte in meinem Rechner und erreiche den SOFS nur über dessen Management-Netz. Weiters wird beim SOFS bzw. der CA Share nichts gecached, auch verständlich. Aber trotzdem sollte ich zumindest 50-60 MB erreichen? Vor allem der Metadaten-Overhead hält sich in grenzen wenn eine VHDX mit 20 GB kopiert wird.

    Sodann war mein Gedanke, der Fehler muss im Storage liegen. Daher habe ich folgende Tests durchgeführt:
    a) Kopieren einer Datei mit mehreren GB am SOFS Node direkt vom lokalen Speicher in das Verzeichnis des CSV: Sprich c:\clusterStorage\Volume1 - das passt rund 180MB/s werden erreicht. Zusätzlich mit SQLIO gestestet und bestätigt.

    b) Erstellen einer zusätzlichen "normalen" Fileserver Rolle - Laufwerk erstellt und einem der Nodes zugewiesen.
    Wieder eine Datei kopiert, lokaler Speicher an Clusterstorage (Laufwerk N:)
    Selbe Ergebnisse. Also kanns/wirds nicht am Storage selbst liegen?


    Was ich mittlerweile alles probiert habe:
    - Natürlich alle Update und Treiber und Firmwares aktualisiert (HP, NIC, HBA, JBOD), wurde schon bei der Installation gemacht und jetzt nochmal gecheckt.
    - mit SmbMultichannelConstraint experimentiert, da ich zuerst vermutete es werden die falschen NICs verwendet - es wäre ja als Fallback auch möglich über das Management-Netz den Storage-Verkehr abzuwickeln, aber die Reihenfolge der Bindungen und die Metric lt. Anleitung wurde beachtet.
    - Jumbo-Frames aktiviert/deaktiviert
    - Am Server und in Windows alle Stromspar-Funktionen deaktiviert (da gabs einen Artikel darüber)
    - CSV mit verschiedenen Konfigurationen (Parity, Spiegel) und verschiedenen Columns getestet


    Trotzdem erreiche ich beim Zugriff auf die SOFS-Share immer nur rund 20MB/s. Was auch auffällt, das öffnen der Shares selbst dauert ewig. Also wenn ich von meinem Arbeitsplatz darauf zugreife, vergehen sicher mal 15-20 Sekunden bis die Ordner und Dateien der VMs zu sehen sind.

    Ich habe auch schon einen bestehenden Hyper-V Host in den Cluster aufgenommen, da die dort lokal gespeicherten VMs auf den neuen Storage umziehen sollten. Wenn ich da eine Speicher-Livemigration mache, sehe ich im Resourcenmonitor das selbe Bild. Die vhdx wird mit rund 20MB/s geschrieben, obwohl dieser Host auch schon die 10GE Ports hat, und auch im Storage-Netz hängt. Auch im Assistent zum Verschieben der VM Dateien dauert es "ewig" wenn ich die SOFS Share hinzufüge, bis ich die dortigen Dateien sehe.

    Ich weiß nun nicht mehr so Recht wo ich ansetzen soll? Oder jage ich ein Gespenst? Zum einen kann ich innerhalb der Test-VM jetzt keine erhebliche Performanceschwäche feststellen, zum anderen gibts ja zu Hauf Artikel wo immer darauf hingewiesen wird, dass der Zugriff auf den SOFS nicht mal einfach so zu bewerten ist. Aber irgendwie muss ich ja etliche VMs dort hinkopieren und wenn das nur mit 20MB läuft, dauert das eine Weile...

    Hat jemand eine Idee?
    Vor allem wie kann ich weitere Tests (möglichst Sinnvolle) anstellen um den möglicherweise vorhandenen Flaschenhals zu finden?

    Vielen Dank
    Marcus Pink

    Donnerstag, 13. August 2015 09:18

Antworten

  • Hi Marcus,

    lies Dir das zum Thema Parity und Hyper-V durch:

    http://www.aidanfinn.com/2013/12/flow-of-storage-traffic-in-hyper-v-over-smb-3-0-to-ws2012-r2-sofs/

    Gruss/Regards Marcel | http://www.windowspro.de/marcel-kueppers

    Mittwoch, 19. August 2015 10:02
  • Hi, 

    du hast bei Parity ganz normal eine geringe Performance als bei Mirror. Du kannst es dir ähnlich vorstellen wie bei RAID 1 und RAID 5. 

    Bei den Platten und der Parity ist dein Performance eigentlich normal und mehr ist leider nicht zu erwarten. Du hast bei Storage Spaces eben auch kein Hardware RAID sondern eine Software basierte Lösung. 

    In der Praxis reicht der 3 Wege Mirror bei Storage Spaces, hier kannst du einen Enclosure inkl. Platten verlieren und dier Performance leidet nicht. Parity ist dann eher für die "Übervorsichtigen".

    Achte beim 3 Wege Spiegel aber immer darauf, dass deine Platten Typen durch 3 teilbar bleiben. Also 3x 146GB SAS, 3x 300GB SAS etc. und dann alle gleichmässig auf die Enclosure verteilt sind.

    1x 146 & 300 GB in Enclosure 1 

    1x 146 & 300 GB in Enclosure 2 

    1x 146 & 300 GB in Enclosure 3 

    An deiner Stelle würde ich noch ein Paar SSDs reinsetzen. Hier gilt, lieber viele kleine SSDs als wenige große. So bekommst du wesentlich mehr Performance aus den Storage Spaces. 

    Hast du bei den Platten auch darauf geachtet, dass sie Storage Spaces supporten, sprich SCSI3 Commands mit SCSI Persistent Reservations ? 

    Beste Grüße

    Flo 

    Mittwoch, 19. August 2015 12:02

Alle Antworten

  • Hallo Marcus, 

    wie du ja schon sagtes die reine Kopierrate gibt dir keine Auskunft über die Performance des SoFS. Ein Scale out Fileserver ist rein auf IOs getrimmt. 

    Um alles etwas besser zu analysieren, könntest du eventuell mit IOMeter schauen wieviele IOPS du aus deinem Scale out Fileserver bekommst. 

    Dafür einfach ein Volume auf einem deiner erstellen und von einem deiner Hyper-V Hosts mal IOMeter drauf laufen lassen. 

    Wieviele LUNs / Shares stellst du über die SoFS für das Cluster bereit? Du solltest eigentlich pro SoFS 1 Share bereitstellen um redirected traffic zu vermeiden. 

    LG

    Flo 

    Freitag, 14. August 2015 06:18
  • Hallo Flo,

    danke mal für deine Auskunft. Du meinst pro SOFS Node eine Share bzw. eigentlich ein CSV Datenträger, oder? Das ist mir bewusst, derzeit sinds allerdings 6 shares, aus Migrationsgründen.

    Zukünftig werden es wohl trotzdem mind. drei Shares sein, da geplant ist drei Pools anzulegen, da wir drei verschiedene Plattentypen für verschiedene Einsatzzwecke eingeplant haben.

    Oder wäre es sinnvoller einen großen Pool anzulegen, und bei de Erstellung der Datenträger per Powershell zu bestimmen welche Platten aus dem Pool verwendet werden sollen?

    Grundsätzlich steht aber in sämtlichen Artikeln lediglich dass es pro Node mind. einen Datenträger geben soll um eine Lastverteilung zu erreichen. Das mehr nicht möglich bzw. sinnvoll sind habe ich jetzt nirgens gelesen.

    Testen kann ich das nächste Woche mal, bin heute nicht im Büro.

    lg

    Marcus

    Freitag, 14. August 2015 06:37
  • Hallo Marcus, 

    ein CSV/Share/Datenträger pro Knoten ist Best Practice aber es können auch mehr sein. Kein Problem. 

    Das ihr mehrere Volumes plant und darüber dann Storage Klassifizierung macht ist auch super. Spricht also nichts gegen eure Konfiguration. Es gibt noch ein paar Sachen die wichtig sind. Schau mal bitte über den Post von Carsten Rachfahl und Jan Kappen, da hast du eigentlich alles wichtige für nen SoFS mit DAS Storage drin. 

    Weitere Best-Practises beim Aufbau und Betrieb der Microsoft Storage Spaces im Failover Cluster (Scale-Out File Server) (Update 1)

    Windows-Update im Scale-Out Fileserver erzeugt Probleme bei der Arbeit mit Datenträgern im Failover Cluster (Update 2)

    Unsere Best Practise-Erfahrungen – Teil 2 – Die Installation und Einrichtung eines Scale-Out Fileserver unter Windows Server 2012 R2

    Überprüfung und Überwachung eines Scale-Out File Server mit dem Test-StorageHealth Skript

    LG

    Flo 

    Freitag, 14. August 2015 08:41
  • Vielleicht bringt es Dich weiter, wenn Du Dich mit SMB (speziell MultiChannel und Direct) noch etwas auseinandersetzt:

    http://blogs.technet.com/b/josebda/archive/2012/05/13/the-basics-of-smb-multichannel-a-feature-of-windows-server-2012-and-smb-3-0.aspx


    Gruss/Regards Marcel | http://www.windowspro.de/marcel-kueppers

    Mittwoch, 19. August 2015 09:33
  • Hallo,

    danke erstmal für eure Hinweise. Also nach weiteren Tests hat sich herausgestellt, dass lediglich die virtuellen Datenträger die als Parity-Datenträger angelegt wurden, dieses Phänomen aufweisen. Also ich habe wie folgt getestet:

    CSV Datenträger 3-Wege Mirror mit 64 KB Interleave, zwei Columns (!)
    64k seq Read: 3713 IOPS und 243 MB / sek
    64k seq Write: 2383 IOPS und 156 MB / sek

    CSV Datenträger mit Parity, 64KB Interleave, acht Columns (!)
    64k seq Read: 8536 IOPS und 559 MB /sek
    64k seq Write: 1153 IOPS und 75MB / sek (!!!)

    Die Werte wurden aus einer VM mit IOMeter gemessen und zusätzlich mit sqlio geprüft. sqlio gibt etwas niedrigere Werte aus, aber im Rahmen.

    Weitere Recherchen ergeben, dass auch viele andere bei Parity-Datenträgern Performance-Probleme melden, also so wie es aussieht ist das nicht wirklich nutzbar. Ich habe auch versucht den Pool auf IsPowerProtected zu setzen, aber das bringt auch nichts. Write-Chache der Datenträger habe ich noch nicht aktiviert.

    Gibts andere Tricks für Parity-Datenträger?

    Andererseits erkenne ich keine Performance-Probleme wenn ich den Clusterdatenträger (also einen Parity-Datenträger genau gesagt), einer "normalen" Dateiserver-Rolle zuweise, eine Freigabe im Cluster anlege und dann Daten hinkopiere. Eine 6GB ISO Datei wurde mit 100MB/s kopiert.

    Der feine Unterschied dabei ist, dass es eben eine normale Fileserver Rolle ist, und auf der Share die "Fortlaufende Verfügbarkeit" nicht aktiviert ist. Aber ich kann hier keinen Zusammenhang erkennen.

    lg

    Marcus

    Mittwoch, 19. August 2015 09:55
  • Hi Marcus,

    lies Dir das zum Thema Parity und Hyper-V durch:

    http://www.aidanfinn.com/2013/12/flow-of-storage-traffic-in-hyper-v-over-smb-3-0-to-ws2012-r2-sofs/

    Gruss/Regards Marcel | http://www.windowspro.de/marcel-kueppers

    Mittwoch, 19. August 2015 10:02
  • Hast Du Dich auch schon mal mit dem CSV Cache beschäftigt? Ist zwar nur lesend, aber evtl. von Interesse:

    https://www.windowspro.de/marcel-kueppers/hyper-v-cluster-shared-volumes-anlegen-konfigurieren

    Es gibt natürlich auch noch TechNet Artikel.


    Gruss/Regards Marcel | http://www.windowspro.de/marcel-kueppers

    Mittwoch, 19. August 2015 10:17
  • Moin Marcus, 

    wie Marcel schon gesagt hat, kann der CSV Cache schon etwa Abhilfe schaffen. 

    CONFIGURE CSV CACHE IN WINDOWS SERVER 2012 R2

    WICHTIG!!!! Wenn du tiering benutzt dann kannst du keinen CSV Cache mehr benutzen. Die gehen nicht zusammen. 

    Was mir aber schwant ist, dass deine SAS und nSAS Platten von der IO Leistung einfach ausgelastet sind. Kannst du mir vll kurz den Aufbau deiner Diskpools geben sprich welche und wieviele Platten pro Pool und virtueller Disk? Ich müsste mal was rechnen. 

    Hier mal ein Beispiel wieviele IOPS man pro Disk erwarten kann (ohne RAID Level). 

    Device      Type  IOPS             Interface
     =========== ===== ================ ===========
     7,200 rpm   SATA/nSAS  ~75-100 IOPS  SATA 3 Gb/s
     10,000 rpm  SAS   ~140 IOPS     SAS
     15,000 rpm  SAS   ~175-210 IOPS SAS

    SSDs bringen je nach Güte min. 10.000 IOPS 

    LG

    Flo 



    Mittwoch, 19. August 2015 11:07
  • Hallo Flo,

    ich habe den Pool schon wieder zerstört :-)

    Aber die folgenden Informationen kann ich dir trotzdem geben:

    Der Pool wurde aus 4x 146 GB SAS DP 10k und 4x 300 GB SAS DP 10k Platten gebildet. Bzw. auch mal nur aus den vier von der jeweiligen Größe. Da ich 3 JBODs verwende, habe ich auch mal 6 Platten verwendet.

    Da es wie gesagt ein Testaufbau ist, habe ich jetzt leider keine Infos mehr, welche Platten genau für die vDisk genutzt wurden, aber aufgrund der Column-Anzahl von 2 bzw. 8 in meinem Test, ergibt sich das eh.

    Die drei Jobs hängen jeweils separat an einem LSI 9206-16e pro Cluster Node.

    Aber wie schon oben gesagt, ich kann nur dann die schlechte Performance feststellen, wenn der CSV-Datenträger mit Parity erstellt ist. Mirror funktioniert erwartungsgemäß.

    lg

    Marcus

    Mittwoch, 19. August 2015 11:46
  • :-) ok, wenn Aidan Finn das sagt, werde keine Parity datenträger für Hyper-V verwenden

    Aber bei all der Recherchen (und ich habe sicher die letzten beiden Wochen nur darüber gelesen) hatte ich diesen Artikel nicht gefunden. Obwohl darin auch nicht wirklich begründet wird warum, aber nachdem es nicht supported ist, werde ich das wohl akzeptieren müssen.

    lg

    Marcus

    Mittwoch, 19. August 2015 11:49
  • Hi, 

    du hast bei Parity ganz normal eine geringe Performance als bei Mirror. Du kannst es dir ähnlich vorstellen wie bei RAID 1 und RAID 5. 

    Bei den Platten und der Parity ist dein Performance eigentlich normal und mehr ist leider nicht zu erwarten. Du hast bei Storage Spaces eben auch kein Hardware RAID sondern eine Software basierte Lösung. 

    In der Praxis reicht der 3 Wege Mirror bei Storage Spaces, hier kannst du einen Enclosure inkl. Platten verlieren und dier Performance leidet nicht. Parity ist dann eher für die "Übervorsichtigen".

    Achte beim 3 Wege Spiegel aber immer darauf, dass deine Platten Typen durch 3 teilbar bleiben. Also 3x 146GB SAS, 3x 300GB SAS etc. und dann alle gleichmässig auf die Enclosure verteilt sind.

    1x 146 & 300 GB in Enclosure 1 

    1x 146 & 300 GB in Enclosure 2 

    1x 146 & 300 GB in Enclosure 3 

    An deiner Stelle würde ich noch ein Paar SSDs reinsetzen. Hier gilt, lieber viele kleine SSDs als wenige große. So bekommst du wesentlich mehr Performance aus den Storage Spaces. 

    Hast du bei den Platten auch darauf geachtet, dass sie Storage Spaces supporten, sprich SCSI3 Commands mit SCSI Persistent Reservations ? 

    Beste Grüße

    Flo 

    Mittwoch, 19. August 2015 12:02
  • Aidan schreibt einfach zuviel ;) Da kann man schonmal einen Blog übersehen :D Ich kann ihn ja nächstes mal wenn ich ihn sehe dran erinner die wichtigen Sachen zu Highlighten :D 

    LG

    Flo 

    P.s. Wenn deine Frage damit beantwortet ist, bitte den Thread dann auch schliessen und mir Marcel als Beantworter markieren :) Danke :) 

    Wenn du noch Tipps und Tricks brauchst, einfach ins Forum schreiben oder du kannst mich auch direkt anmailen. 

    Mittwoch, 19. August 2015 12:10
  • Danke euch für die Hilfe. Wenns noch was gibt melde ich mich wieder :-)

    Mittwoch, 19. August 2015 16:30
  • Gerne :) Wenns geholfen hat, perfekt.

    Gruss/Regards Marcel | http://www.windowspro.de/marcel-kueppers

    Mittwoch, 19. August 2015 16:47