iSCSI vs. SMB

[PaulBrause]

Ich verwende zwei RS3614xs+ in einem SHA Cluster mit je einer Intel X540-T2 10GbE NIC.
Auf einem Server 2012 R2 auch mit einer 10GbE NIC habe ich zwei Remote-Laufwerke verbunden:
Eins ist ein iSCSI LUN (Block-Niveau), das andere eine VHDX-Datei auf dem SMB2-Share.

Ein Test mit CrystalDiskMark zeigt, dass die über SMB angeschlossene Festplatte erheblich schneller ist als das iSCSI-LUN.
Die Geschwindigkeit von iSCSI schwankt zwischen 16MB/s und 210MB/s hingegen liegt SMB bei um die 750MB/s.

Gibt es irgendeinen Grund warum das iSCSI so langsam ist und die Geschwindigkeit stark schwankt?

 

[PaulBrause]

Nachdem ich ein Ticket bei Synology aufgemacht habe, scheint es "eine Performance Einschränkung beim Block basierten LUN zu geben, die in DSM 6.1 bisher nicht bekannt war" zu geben.
Leider gibt es für dieses Verhalten kein Workaround.

Ich werde jetzt alle virtuellen Maschinen die eine Festplatte auf meinem iSCSI-Storage haben auf SMB umziehen.

Für meine physikalischen Server ist dies aber nicht praktikabel, da angefügte VHD(x)-Dateien nach einem Neustart oder falls der Speicherort nicht mehr verfügbar ist dauerhaft getrennt bleiben.
Falls da einer eine Idee für eine Lösung hat; Ich bin ganz Ohr!

 

[amarthius]

Wird das dann in einem Update behoben oder ist das by Design so?

 

[PaulBrause]

Es scheint eine Problem mit der internen iSCSI-Version 4.x zu sein.
Ich habe zuvor auf Version 4.0 zurückgestellt, dann lief es wieder schneller, aber mit SHA-Fehlermeldungen.

Ob, wie und wann das mit einem DMS-Update behoben wird kann ich nicht sagen.

 

[PaulBrause]

Das neuste Update 6.1.3-15152 Update 3 hat leider keine Abhife gebracht.
Eher im Gegenteil.
Nachdem die iSCSI-Verbindungen nach dem Neustart für 1-2 Tage wieder "normal" schnell waren, dieses Phänomen hatte ich zuvor nach einem Neustart ebenfalls beobachtet, ist jetzt die Geschwindigkeit katastrophal.
Die Übertragungsgeschwindigkeit schwankt stark zwischen >1MB/s und 60MB/s, liegt hauptsählcih aber bei wenigen MB/s.

Ich werde erneut den Support um Hilfe fragen, gehe aber nicht davon aus, dass es kurzfristig eine "Lösung" für diese Problem gibt.

 

[PaulBrause]

Ich habe den Support nicht kontaktiert, da sich mittlerweile das System scheinabr wieder "gefangen" zu haben scheint.
Die Übertragungsraten beim Veeam Backup liegen wieder bei Werten von über 300MB/s.
Einzig das Kopieren von einem auf ein anderes iSCSI-Target die sich beide auf der Storage befinden habe ich Raten von weniger als 20MB/s.
Deshalb habe ich für Oktober die Installation von 6.1.3-15152 Update 4, welches Verbesserungen bei iSCSI und RAID bringen soll, eingeplant.

 

[PaulBrause]

Das Update 4 werde ich nicht installieren, da ich mittlerweile eine Rückmeldung vom Support habe, dass dieses Update nur spezielle iSCSI-Fehler behebt.
Stattdessen wurde mir empfohlen auf die 6.2 Beta zu achten, die im Oktober vorgestellt werden wird.

 

[blurrrr]

Hallo Paul und danke für Deine ausführlichen Schilderungen!

Hatte es selbst mal in Erwägung gezogen, bin dann aber schlussendlich bei NFS geblieben. So "wirklich" im Business-Sektor scheint es ja leider nicht vorwärts zu gehen (z.B. auch VLAN-Trunk beim VMM), kommt halt alles von der Privatuser-Schiene :/ Ich habe leider auch ein wenig den Eindruck, dass es eher so nach dem Motto geht "och, das können wir noch machen, och, dies auch... vielleicht noch das? usw.).Die im Ausland vorgestellte "Enterprise"-Firewall ("DSM -> SRM -> Enterprise-Firewall"?! Ist auch so eine Art von: "NAS? Können wir... mh... SOHO-Router! SRM!... können wir... mhh.... Enterprise-Firewall!) ist ja auch bis heute nicht in Deutschland erwähnt worden und anscheinend auch in der Versenkung verschwunden. Finde es trotzdem ein wenig... fragwürdig, grade in Anbetracht, dass Privatleute auch mal gern "rumspielen", während es im Enterprise-Sektor doch eher im Performance und Stabilität geht (die Hardware ist ja auch nicht "billig", habe selbst ein paar im RZ). Hoffe auf Deiner Hardware liefen keine produktiven VMs, wo mitunter auch noch zig Leute drauf gearbeitet haben

Schönen Gruß
blurrrr

 

[PaulBrause]

Nur mal zur Info:
Ich bin immer noch auf 6.1.3-15152 Update 3 und krebse mit 7 bis 45MB/s bei einigen Veeam-Sicherungen herum.

Der Release von 6.2 lässt ja auf sich warten.
Außerdem würde ich auf unserem produktiven System nie den ersten Release installieren, sonder immer die unvermeidbare Updatewelle abwarten.

Desweiteren bin ich gespannt welche Vorteile durch 6.2 sich mir im Bezug auf iSCSI tatsächlich bieten, denn in den ReleaseNotes von 6.2Beta (https://www.synology.com/de-de/beta/DSM62Beta/release_note) steht, dass die Block-Level-LUNs nicht mehr unterstützt werden.
Lediglich Block-Level-LUNs aus vor dem Upgrade laufen noch.
Ich gehe davon aus, dass diese dann in einem Legacymode laufen und keine bessere Performance liefern.
Folglich muss ich alle meine 16 Block-Level-LUNs in "Advanced LUNs" umwandeln -> 35TB

 

[mdn_united]

So, jetzt ist ja 6.2 freigegeben worden und mich würde interessieren, ob die Probleme sich verringert haben.

 

[ottosykora]

kann mich jemand aufklären, wozu wurde nun automatisch ohne zu fragen iSCSI manager installiert und lässt sich nicht deinstallieren wenn ich keine iSCSI verwende?

 

[Matthieu]

Bisher war das ganze im DSM hart integriert (primär im Speicher-Manager), jetzt hat es eine eigene Benutzeroberfläche bekommen. Eine "App" ist es deswegen trotzdem noch nicht, siehe auch Changelog. HA2.0 kann man sich als Gegenbeispiel anschauen, das ist in eine eigene "App" gewandert.

MfG Matthieu

 

[frankyst72]

darum geht es in diesem Thread nicht! Bitte eigenen Thread erstellen. Ich vermute dass iSCSCI eine Grundfunktionalität von DSM darstellt und somit der Manager bei jedem installiert wird. Einfach nicht verwenden, wenn Du ihn nicht brauchst.

Mich würde aber trotzdem interessieren, ob die iSCSI-Performance mit DSM 6.2. verbessert wurde? Habt Ihr eigentlich BTRFS oder EXT4 verwendet, oder spielt das da nicht mit rein?

 

[PaulBrause]

Ich habe das Cluster jetzt auf DSM 6.2 aktualisiert.

Um eine Fehlkonfiguration (eine nicht benötigte Cluster-Netzwerkschnittstelle) und auch ggf. Altlasten nicht mit in die neue DSM Version zu übernehmen, bin ich wie folgt vorgegangen:
- Cluster aufgebrochen
- Auf jeder RackStation DSM 6.2-23739 Update 2 installiert
- Das Cluster wieder zusammen geführt

Außer das beim Synchronisieren der 54,5 TB Fehler auf einer der zwölf Festplatten gefunden wurden, gab es keine Probleme.
Nachdem das Cluster vollständig synchronisiert war (Dauer fast genau 72 Stunden) und nach dem Wechsel der "defekten" Platte das RAID 6 wiederhergestellt wurde (Dauer etwa 96 Stunden), läuft das System einwandfrei.

Die Performance beim Veeam Backup von einem iSCSI-Lun auf ein anderes iSCSI-Lun liegt immernoch zwischen 15 und 40 MB/s.
Es überrascht mich nicht, denn die LUNs laufen jetzt in einer Art "Legacy Mode" noch immer als Block-Level-Luns und liegen nach wie vor direkt auf dem Speicherpool vom RAID6.

In einem nächsten Schritt werde ich die Backups auf ein neues File-Lun auf einem BTRFS Volume verschiebn, dazu muss ich aber erst Platz schaffen.

 

[mexx81]

Bleib mal am Ball mit Deinen Analysen. Finde ich sehr gut. Ich habe ebenfalls ein DSM 6.2 HA Cluster mit iSCSI LUNs an einen ESXi im Kundeneinsatz. Komme da leider nicht dazu Performancetests zu machen. Daher finde ich Deine Ergebnisse sehr interessant. Also Danke!!

 

[PaulBrause]

Ich habe die Veeam Sicherungen vom Block-Level-LUN auf ein neues File-Level-LUN das auf einem BTRFS Volumen liegt verschoben.
Das Verschieben hat sehr lange gedauert und hat in der Geschwindigkeit sehr stark geschwankt.

Letztendlich habe ich aktuell jedoch keinen Geschwindigkeitsvorteil mit dem BTRFS-LUN.
Alle Sicherungen laufen mit den gleichen Datenraten und in der gleichen Zeit wie zuvor.

Ich hoffe das es daran liegt, dass die Daten nach wie vor von einem Block-Level-LUN gelesen werden.
Die alten LUNs aber in neue BTRFS-LUNs umzuwandeln kann ich nicht mal eben, weil darauf unsere produktiven Daten liegen.