8
SMB Traffic (:445) auf einem Windows Server zeitgesteuert einbremsen?
Hallo,
ich habe ich eine -leicht- komische Anforderung.
Wir haben eine Softwareverteilung die leider immer wieder "amok" läuft. D.h. Repositorys werden unter Tags (ausserhalb der definierten Zeiten) ausgerollt an unsere Standorte.
Dabei kommt es immer wieder zu Leitungsengpässen.
Beim Hersteller der SW kommen wir derzeit mit keiner Lösung weiter.
Daher dachten wir uns, ob es evtl. ein Tool gibt, bei dem ich SMB Traffic Port 445 systemseitig ausbremsen kann?
D.h. entweder auf unserem zentralen SW-Verteilungsserver, oder aber auch auf unseren Standortservern?
Der normale Filetraffic / Filesync wird bei uns mit DFSR gemacht. Somit gibt es ausser der SW_Verteilung kein SMB.
Die Standortserver laufen mit Win 2012, SW-Verteilserver noch auf Win2003R2.
Kennt jemand eine solche Software, die es zeitgesteuert ermöglicht TCP Port 445 Traffic auszubremsen bzw. zu blockieren?
Der eigentliche Sync soll immer nur nachts stattfinden.
ich habe ich eine -leicht- komische Anforderung.
Wir haben eine Softwareverteilung die leider immer wieder "amok" läuft. D.h. Repositorys werden unter Tags (ausserhalb der definierten Zeiten) ausgerollt an unsere Standorte.
Dabei kommt es immer wieder zu Leitungsengpässen.
Beim Hersteller der SW kommen wir derzeit mit keiner Lösung weiter.
Daher dachten wir uns, ob es evtl. ein Tool gibt, bei dem ich SMB Traffic Port 445 systemseitig ausbremsen kann?
D.h. entweder auf unserem zentralen SW-Verteilungsserver, oder aber auch auf unseren Standortservern?
Der normale Filetraffic / Filesync wird bei uns mit DFSR gemacht. Somit gibt es ausser der SW_Verteilung kein SMB.
Die Standortserver laufen mit Win 2012, SW-Verteilserver noch auf Win2003R2.
Kennt jemand eine solche Software, die es zeitgesteuert ermöglicht TCP Port 445 Traffic auszubremsen bzw. zu blockieren?
Der eigentliche Sync soll immer nur nachts stattfinden.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 239894
Url: https://administrator.de/contentid/239894
Ausgedruckt am: 21.11.2024 um 18:11 Uhr
8 Kommentare
Neuester Kommentar
Hallo Mastermind,
auch der Zugriff auf ein per DFS-R synchronisiertes Verzeichnis erfolgt meist per SMB, zumindest zu den weiterverarbeitenden Clients.
Aber um was für eine Software handelt es sich, vielleicht liegt das Problem an einer ganz anderen Stelle.
Grüße,
Christian
auch der Zugriff auf ein per DFS-R synchronisiertes Verzeichnis erfolgt meist per SMB, zumindest zu den weiterverarbeitenden Clients.
Aber um was für eine Software handelt es sich, vielleicht liegt das Problem an einer ganz anderen Stelle.
Grüße,
Christian
Danke für den Hinweis... Daran habe ich gar nicht gedacht. Klar die Clients draussen, greifen per SMB Share auf die Daten zu...
Ein Tool müsste somit auf dem Softwareverteilungsserver eingesetzt werden. Dort läuft sonst nichts...
Das SW Verteilungstool heißt Matrix42 / Empirum.
Es gibt dort zwar Optionen beim Filesync die es ermöglichen eine Synchronisation zu einem bestimmten Zeitpunkt zu unterbinden....
Aber leider funktioniert das immer mal wieder nicht....
Ich hatte bisher nur mit Frontrange Enteo zu tun... da gab es solche Probleme nicht
Matrix42 betreue ich nicht, von daher, kann ich dazu nicht mehr sagen, als ich von meinen Kollegen als Antwort bekomme..
Ich bin an dem Ende der Kette, wo es um Leitungsperformance geht. Wenn klagen kommen, bin ich dran....
Daher möchte ich mich mit einer solchen Lösung absichern...
Mir fehlt die Zeit mich immer wieder um das SW-Verteilungsproblem zu kümmern....
Ein Tool müsste somit auf dem Softwareverteilungsserver eingesetzt werden. Dort läuft sonst nichts...
Das SW Verteilungstool heißt Matrix42 / Empirum.
Es gibt dort zwar Optionen beim Filesync die es ermöglichen eine Synchronisation zu einem bestimmten Zeitpunkt zu unterbinden....
Aber leider funktioniert das immer mal wieder nicht....
Ich hatte bisher nur mit Frontrange Enteo zu tun... da gab es solche Probleme nicht
Matrix42 betreue ich nicht, von daher, kann ich dazu nicht mehr sagen, als ich von meinen Kollegen als Antwort bekomme..
Ich bin an dem Ende der Kette, wo es um Leitungsperformance geht. Wenn klagen kommen, bin ich dran....
Daher möchte ich mich mit einer solchen Lösung absichern...
Mir fehlt die Zeit mich immer wieder um das SW-Verteilungsproblem zu kümmern....
Dachte ich mir ;)
Wurde das Netz denn schon auf Probleme analysiert?
Wurde das Netz denn schon auf Probleme analysiert?
Das Netz basiert auf MPLS Leitungen + WAN Optimierer.
Selbst mit WAN Optimierung ist die Leitung überbucht. Durch diese Überbuchung gibt es sog. Paket Drops. Es gibt zwar sog. Klassifizierung auf unserer MPLS Leitung. Aber wenn alles voll ist, dann kommt es trotzdem zu verzögertem Verhalten bei niedrig klassifiziertem Traffic...
Durch unsere WAN Optimierung + Trafficeanalysetools bin ich ja letztlich auf die Softwareverteilung als Problemverursacher gekommen.
Dort laufen halt regelmäßig mehrere GByte über schmalbandige ADSL/SDSL Leitungen - von daher ist die Leitung nicht sehr "groß".
(ADSL DL/UL 1536Kbit/192Kbit)
(SDSL DL/UL 512Kbit/512Kbit)
Wenn die Softwareverteilung wie gewünscht -ausserhalb- der Arbeitszeiten synct, habe ich mit der Leitungsauslastung keine Probleme.
Die WAN Optimierer machen Ihre Arbeit ansonsten sehr gut! (MAPI, Citrix, ...)
Selbst mit WAN Optimierung ist die Leitung überbucht. Durch diese Überbuchung gibt es sog. Paket Drops. Es gibt zwar sog. Klassifizierung auf unserer MPLS Leitung. Aber wenn alles voll ist, dann kommt es trotzdem zu verzögertem Verhalten bei niedrig klassifiziertem Traffic...
Durch unsere WAN Optimierung + Trafficeanalysetools bin ich ja letztlich auf die Softwareverteilung als Problemverursacher gekommen.
Dort laufen halt regelmäßig mehrere GByte über schmalbandige ADSL/SDSL Leitungen - von daher ist die Leitung nicht sehr "groß".
(ADSL DL/UL 1536Kbit/192Kbit)
(SDSL DL/UL 512Kbit/512Kbit)
Wenn die Softwareverteilung wie gewünscht -ausserhalb- der Arbeitszeiten synct, habe ich mit der Leitungsauslastung keine Probleme.
Die WAN Optimierer machen Ihre Arbeit ansonsten sehr gut! (MAPI, Citrix, ...)
Bei den Umgebungsdaten bleibt wohl kaum mehr über als ein zusätzlicher Server auf der anderen Seite für die SW Verteilung. So wie es scheint wird der Sync nachts einfach nicht fertig (wundert auch nicht).
Ein zusätzlicher Server in den Filialen denke ich wird nicht benötigt. Es reicht ja aus, wenn ich an dem zentralen Softwareverteilungsserver SMB ausbremse.
Der Server verteilt die Pakete zentral an jeden Standort... Wenn ich das dort einbremse - würde das ja passen....
Letzlich suche ich nun ein Tool das so etwas kann?
Die Umgebungsdaten sind immer gleich.
ZIEL-IPs / Quell IP / Shareverzeichnis / Port / Protokoll sind immer gleich.
Kennt jemand ein solches Tool
Der Server verteilt die Pakete zentral an jeden Standort... Wenn ich das dort einbremse - würde das ja passen....
Letzlich suche ich nun ein Tool das so etwas kann?
Die Umgebungsdaten sind immer gleich.
ZIEL-IPs / Quell IP / Shareverzeichnis / Port / Protokoll sind immer gleich.
Kennt jemand ein solches Tool
Dann eine Firewall. Dann kannst du dir die SW Verteilung aber direkt sparen.
Danke für die Rückinfos.... aufgrund des erhöhten Aufwands bzw. Equipments (was keinen Sinn macht).... wird der Ball zurückgespielt.... Muss der SW Verteilungskollege das Problem nochmals beim Hersteller einkippen mit endgültiger Lösung.
