tobitobsn
Goto Top

Schwankende Abfrage Performance über VPN

Problem: Ein Kunde hat zwei Standorte, welche jeweils über einen ADSL Anschluß (16MBit) verfügen. Eckdaten der Anschlüsse: beide um 14-16MBit/s Downstream und 2,5-2,7MBit/s Upstream mit Rauschabständen von 7-8dB.

Weiterhin ist dort ein IPSec VPN realisiert, welches zwischen den beiden Lancom Routern (1781er) aufgebaut ist.

Der grundsätzliche Zugriff läuft sauber und zuverlässig und alles sieht ganz gut aus. Nun wird an Standort 1 mit PCs auf einen Webserver an Standort 2 zugegriffen und Anfragen ausgelöst. Die Anfragen laufen gegen ein lokales ERP System mit lokaler DB. Wenn man morgens die Rechner startet, läuft alles gut und die Anfragen werden in der Regel innerhalb von 2-3 Sekunden beantwortet. Sobald aber 5-6 PCs in Betrieb sind und regelmäßig Anfragen abschicken, schwankt die Ausführungszeit auf bis zu 25-30 Sekunden.

Wo kann hier der Hase im Pfeffer liegen?

Content-Key: 381417

Url: https://administrator.de/contentid/381417

Ausgedruckt am: 28.03.2024 um 17:03 Uhr

Mitglied: Looser27
Looser27 26.07.2018 um 20:11:40 Uhr
Goto Top
Die arbeiten direkt auf dem Zielsystem oder über eine Remote Sitzung?
Vermutlich reicht die Bandbreite nicht für die Anzahl User aus.
Mitglied: tobitobsn
tobitobsn 26.07.2018 aktualisiert um 21:17:19 Uhr
Goto Top
Es wird direkt auf dem Zielsystem gearbeitet. Es ist ein Webserver, der per https über das VPN aufgerufen wird.

Die Router wurden vor kurzem ausgetauscht. Vorher waren da Fritzbox dran. Da gab es zwar regelmäßig Qualitätsprobleme, da dort auch 2-3 SIP Telefone drüber laufen und diese damals immer geknistert haben, was nun nicht mehr der Fall ist, aber diese stark schwankende Performance der Abfragen gab es mit den Fritzboxen nicht.
Mitglied: Looser27
Looser27 26.07.2018 um 21:18:58 Uhr
Goto Top
Was für Router setzt ihr denn ein?
Mitglied: tobitobsn
tobitobsn 26.07.2018 um 21:30:06 Uhr
Goto Top
Jetzt Lancom 1781VA und 1781VA-4G
Mitglied: Looser27
Looser27 26.07.2018 um 22:02:15 Uhr
Goto Top
Ist eine Bandbreiten Beschränkung für das VPN eingerichtet?
Mitglied: tobitobsn
tobitobsn 26.07.2018 um 22:19:52 Uhr
Goto Top
Nein. Das liegt daran, dass der Standort 1 98% aller Aufgaben über das VPN erledigt. Ansonsten passiert an Standort 1 nicht viel. Daher kann die gesamte Bandbreite für das VPN genutzt werden.

Ich habe gerade überlegt, ob es daran liegen kann, dass die Abfragen ja zum großen Teil aus sehr kleinen und vielen Paketen bestehen... Der Kunde hat zum sehr großen Teil sehr günstige nonmanageable Switches im Einsatz, welche wir erst in nächster Zeit gegen hochwertige Switche tauschen wollen.

Könnte das hier das Problem sein?
Mitglied: Spirit-of-Eli
Spirit-of-Eli 27.07.2018 um 01:46:28 Uhr
Goto Top
Was steht denn nun an Bandbreite zu Verfügung und was wird gebraucht?

Alles andere ist doch nur gequatsche um den heißen Brei.

Sind die QoS Einstellungen für die SIP Telefonie korrekt?
Mitglied: brammer
brammer 27.07.2018 um 06:20:08 Uhr
Goto Top
Hallo,

Arbeiten beide Seite wirklich mit DSL? Da der 2. Router den Zusatz 4G hat... ist der an LTE angeschlossen und da kommt dein Problem her?
Das würde die Schwankungen erklären...

Brammer
Mitglied: SeaStorm
SeaStorm 27.07.2018 um 08:23:20 Uhr
Goto Top
wie ist denn die Auslastung der Leitung, wenn es langsam läuft?
Sind es die Response-Zeiten der Pakete, oder ist es der Webserver, der langsamer wird? (mal per Ping getestet?)
Du kannst ja mal per QoS die Verbindung zum Webserver priorisieren
Mitglied: Lochkartenstanzer
Lochkartenstanzer 27.07.2018 aktualisiert um 08:36:36 Uhr
Goto Top
Zitat von @tobitobsn:


Wo kann hier der Hase im Pfeffer liegen?



Moin,

Läuft denn das ERP schnell genug, um die 5-6 Web-Clients zu bedienen. Wieviele Leute arbeiten denn gleichzeit an Standort2. wie sind da die Antwortzeiten über das Webinterface?

Habt ihf den Datendurchsatz und die Latenz der Verbindung gèmessen, z.B. mit ioerf o.ä.?

lks
Mitglied: Looser27
Looser27 27.07.2018 um 09:09:37 Uhr
Goto Top
Zitat von @tobitobsn:

Nein. Das liegt daran, dass der Standort 1 98% aller Aufgaben über das VPN erledigt. Ansonsten passiert an Standort 1 nicht viel. Daher kann die gesamte Bandbreite für das VPN genutzt werden.

Heißt das, dass die ausschließlich über die VPN Verbindung agieren, also auch normales Surfen im Internet sämtliche Telefonie, etc?
Mitglied: ukulele-7
ukulele-7 27.07.2018 um 10:21:31 Uhr
Goto Top
Kann es sein das die Antwortzeiten immer dann hoch gehen wenn die, jetzt nicht mehr knisternden, VoIP Verbindungen aufgebaut werden?
Mitglied: tobitobsn
tobitobsn 27.07.2018 aktualisiert um 17:15:59 Uhr
Goto Top
@Spirit-of-Eli: Bandbreite ist , wie oben geschrieben, 16MBit an beiden Standorten vorhanden. Einer davon hat leider aktuell nur 6dB Rauschabstand (Standort 2), was dürftig ist, aber SIP und normale Daten laufen ohne große Probleme stabil und gut. Die Bandbreite sollte normalerweise ausreichen.

QoS für SIP - nein. Macht grundsätzlich Sinn, aber hier besteht überhaupt kein Problem - siehe Überschrift. Die Webserver/Datenbank macht die Probleme.

@brammer: Ja, der LTE ist aber nur Fallback. Und dieser tritt nur ein, wenn das DSL wegbricht. Tests und Monitoring bestätigen das.

@SeaStorm: Standort 2 lokal läuft das ERP und der Webserver schnell und stabil. Auch mit vielen Standort 2 lokalen Clients. Die Auslastung des Webservers und des ERP Servers ist die ganze Zeit wenig bis mittel - keine Peaks. Ping (klein und groß), sowie iperf sind dauerhaft gut und stabil.

@looser: Ja, es geht alles über das VPN. Allerdings wird sehr wenig telefoniert und nicht ständig. Gesurft wird gar nicht. Die Schwankungen korrelieren nicht mit Telefonaten.

@4400667902: Nein, leider nicht.
Mitglied: brammer
brammer 27.07.2018 um 21:09:54 Uhr
Goto Top
Hallo,

Lass mal einen dauerping von beiden Seite n auf die gegenüberliegende public IP und je eine IP hinter dem Tunnel laufen und beobachte die Laufzeiten.
An beiden Seiten der selbe Provider?
Evtl ist einer oder beide DSLAM überbucht und geht in die Knie....

Brammer
Mitglied: tobitobsn
tobitobsn 30.07.2018 um 18:33:07 Uhr
Goto Top
Jo, bin die Tage mal wieder da. Da werd ich das mal machen und berichten...