5
Probleme mit SMB auf VPLS Gigabit-Strecke
Hallo zusammen,
wir haben Bandbreitenprobleme bei einer VPLS (Layer2) Gigabit-Strecke zwischen zwei Standorten.
Getestet haben wir in beide Richtungen smb/afp:
iMac 10.14/10.13 auf Synology (DSM 6.1.7)
Windows 10 auf Sinology
iMac 10.14/10.13 auf Windows Server 2012 R2
iMac auf iMac
...
Das Resultat - chaotisch! Übertragung immer stark schwankend. Mal ansatzweise Gigabit/s, dann wieder nur 7Mbit/s. In eine Richtung im Schnitt höhere Geschwindigkeiten als in die andere.
Mit anderen Protokollen, zB. http, ftp scheint es keine Probleme zu geben. Auch ipferf und scp übertragen mit relativ konstanten Gigabit/s. Getestet haben wir auch mit Direktverbindung der Hardware, also nur mit den SAS der Carrier und ohne eigene Infrastruktur dazwischen.
Die Latenz (RTT) zwischen den Standorten ist mit 18ms für smb/afp relativ hoch, daher vermuten wir, dass die Ursache an den Round Trips und RPCs liegt. Im Wireshark fallen Abschnitte mit "TCP Dup Ack" und "TCP Out-Of-Order" auf. Mit der TCP Window Size haben wir an den iMacs experimentiert, ohne nennenswerte Verbesserungen zu erzielen.
Meine Frage, kennt jemand das Phänomen und gibt es eine Lösung, um ansatzweise konstant hohe Datenübertragungen mit smb zu erzielen? Vielen Dank für eure Hilfe.
Lenseman
wir haben Bandbreitenprobleme bei einer VPLS (Layer2) Gigabit-Strecke zwischen zwei Standorten.
Getestet haben wir in beide Richtungen smb/afp:
iMac 10.14/10.13 auf Synology (DSM 6.1.7)
Windows 10 auf Sinology
iMac 10.14/10.13 auf Windows Server 2012 R2
iMac auf iMac
...
Das Resultat - chaotisch! Übertragung immer stark schwankend. Mal ansatzweise Gigabit/s, dann wieder nur 7Mbit/s. In eine Richtung im Schnitt höhere Geschwindigkeiten als in die andere.
Mit anderen Protokollen, zB. http, ftp scheint es keine Probleme zu geben. Auch ipferf und scp übertragen mit relativ konstanten Gigabit/s. Getestet haben wir auch mit Direktverbindung der Hardware, also nur mit den SAS der Carrier und ohne eigene Infrastruktur dazwischen.
Die Latenz (RTT) zwischen den Standorten ist mit 18ms für smb/afp relativ hoch, daher vermuten wir, dass die Ursache an den Round Trips und RPCs liegt. Im Wireshark fallen Abschnitte mit "TCP Dup Ack" und "TCP Out-Of-Order" auf. Mit der TCP Window Size haben wir an den iMacs experimentiert, ohne nennenswerte Verbesserungen zu erzielen.
Meine Frage, kennt jemand das Phänomen und gibt es eine Lösung, um ansatzweise konstant hohe Datenübertragungen mit smb zu erzielen? Vielen Dank für eure Hilfe.
Lenseman
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 390358
Url: https://administrator.de/contentid/390358
Printed on: April 26, 2024 at 10:04 o'clock
5 Comments
Latest comment
Ah, vor einigen Jahren mein "Lieblingsthema" , LFN, long fat networks.
Habe aber nichts im Zusammenhang mit SMB dazu gemacht.
Generell hilft bei langen RTTs die Buffer zu erhöhen, les dich in das Thema mal ein: https://blogs.msdn.microsoft.com/openspecification/2009/04/10/smb-maximu ...
(Das ist ein alter Post, hat vermutlich kaum noch relevanz, aber nur so als anhaltspunkt)
Vesuch auch mal ein Linux mit einem Kernel > 4.16, da sind in letzter Zeit einige optimierungen in das Thema eingeflossen.
Am ende des Tages helfen bei LFNs nur Dateiübertragungen auf UDP Basis wie z.b. Aspera oder FileCatalyst - wobei, wenn du schon Synology hast, kannst ja deren "Presto" Dienst mal antesten: (kostet aber etwas)
https://www.synology.com/de-de/dsm/feature/presto
Habe aber nichts im Zusammenhang mit SMB dazu gemacht.
Generell hilft bei langen RTTs die Buffer zu erhöhen, les dich in das Thema mal ein: https://blogs.msdn.microsoft.com/openspecification/2009/04/10/smb-maximu ...
(Das ist ein alter Post, hat vermutlich kaum noch relevanz, aber nur so als anhaltspunkt)
Vesuch auch mal ein Linux mit einem Kernel > 4.16, da sind in letzter Zeit einige optimierungen in das Thema eingeflossen.
Am ende des Tages helfen bei LFNs nur Dateiübertragungen auf UDP Basis wie z.b. Aspera oder FileCatalyst - wobei, wenn du schon Synology hast, kannst ja deren "Presto" Dienst mal antesten: (kostet aber etwas)
https://www.synology.com/de-de/dsm/feature/presto
Hi,
jetzt mal ne ganz doofe Frage..hast du dir die CPU Last der Synology mal angesehen? Ich hatte bei mir auch plötzlich bei smb nen ziemlichen Performance Einbruch was daran lag, dass dann die Verschlüsselung dazu kam und die Synologys es einfach von der Hardware her nicht mehr gepackt haben.
@netzwerk dude
Müsste dann nicht nen OpenVPN via UDP das Problem auch lösen?
LG
Theo
jetzt mal ne ganz doofe Frage..hast du dir die CPU Last der Synology mal angesehen? Ich hatte bei mir auch plötzlich bei smb nen ziemlichen Performance Einbruch was daran lag, dass dann die Verschlüsselung dazu kam und die Synologys es einfach von der Hardware her nicht mehr gepackt haben.
@netzwerk dude
Müsste dann nicht nen OpenVPN via UDP das Problem auch lösen?
LG
Theo
@theoberlin: leider nein, denn die applikation die drüberläuft verwendet ja weiterhin tcp und hat mit den selben hohen RTTs zu kämpfen.
Daher: OpenVPN über UPD macht es nicht schlimmer, hilft aber nicht, da es ja für die applikation transparent ist.
Daher: OpenVPN über UPD macht es nicht schlimmer, hilft aber nicht, da es ja für die applikation transparent ist.
Danke für eure Antworten. 
An den Buffern habe ich schon ohne nennenswerten Erfolg herumgeschraubt. Ich schaue mir den Artikel aber noch mal an. Wir haben recht viele Betriebssysteme im Einsatz, was die Sache nicht einfacher macht.
Presto habe ich schnell getestet -läuft super! Stabile Transferraten um die 100MB/s in beide Richtungen. Der Haken an der Sache, die Kollegen in der Aussenstelle sollen direkt auf einem zentralisierten Speicher in der Zentrale arbeiten. D.h. die Daten werden direkt von den gemounteten Laufwerken in den lokalen Arbeitsspeicher geladen und bearbeitet. Für Presto müssten wir den kompletten Workflow ändern und auch Backup-Strategien anpassen. Wir bräuchten also ein Protokoll mit dem Apple Computer umgehen können. Bei den Daten handelt es sich um große Bild und Videodateien, daher benötigen wir den hohen Durchsatz.
Am liebsten wären mir zwei Geräte, die wir zwischen die Strecken schalten und die dann das Problem lösen (Stichwort WAN Optimierer). Die sollten allerdings auch preislich ins Konzept passen. Hättet ihr dazu vielleicht noch eine Idee?
An den Buffern habe ich schon ohne nennenswerten Erfolg herumgeschraubt. Ich schaue mir den Artikel aber noch mal an. Wir haben recht viele Betriebssysteme im Einsatz, was die Sache nicht einfacher macht.
Presto habe ich schnell getestet -läuft super! Stabile Transferraten um die 100MB/s in beide Richtungen. Der Haken an der Sache, die Kollegen in der Aussenstelle sollen direkt auf einem zentralisierten Speicher in der Zentrale arbeiten. D.h. die Daten werden direkt von den gemounteten Laufwerken in den lokalen Arbeitsspeicher geladen und bearbeitet. Für Presto müssten wir den kompletten Workflow ändern und auch Backup-Strategien anpassen. Wir bräuchten also ein Protokoll mit dem Apple Computer umgehen können. Bei den Daten handelt es sich um große Bild und Videodateien, daher benötigen wir den hohen Durchsatz.
Am liebsten wären mir zwei Geräte, die wir zwischen die Strecken schalten und die dann das Problem lösen (Stichwort WAN Optimierer). Die sollten allerdings auch preislich ins Konzept passen. Hättet ihr dazu vielleicht noch eine Idee?
Ich habe seinerzeit nach dem Artikel etwas rumprobiert, aber wirklich besser wurde es nicht:
https://www.heise.de/select/ix/2016/12/1480593236529397
Lag vielleicht auch daran das ich das hinterste Nest in China anbinden musste mit teilweise RTTs von 350ms - vielleicht wird es bei dir mehr bringen.
PS: Von Presto gibts auch Desktop Clients für viele OSe (Win, Mac, Debian):
https://www.synology.com/de-de/support/download/ioSafe%201515+#utilities
und dazu gibts noch den Automator, mit dem man teilweise Workflows abbilden sollte:
https://originwww.synology.com/de-de/knowledgebase/DSM/help/PrestoAutoma ...
https://www.heise.de/select/ix/2016/12/1480593236529397
Lag vielleicht auch daran das ich das hinterste Nest in China anbinden musste mit teilweise RTTs von 350ms - vielleicht wird es bei dir mehr bringen.
PS: Von Presto gibts auch Desktop Clients für viele OSe (Win, Mac, Debian):
https://www.synology.com/de-de/support/download/ioSafe%201515+#utilities
und dazu gibts noch den Automator, mit dem man teilweise Workflows abbilden sollte:
https://originwww.synology.com/de-de/knowledgebase/DSM/help/PrestoAutoma ...