Merge-Replikation über VPN nicht möglich, aber über LAN problemlos

[gerd33 18]

Hallo zusammen,

Meine Software soll zwischen Server und Client per merge-Replikation synchronisiert werden. Datenbasis ist SQL Server 2014 Standard Serverseitig und SQL Server 2014 Express am dem Notebook.

Die Replikation wird durch die Software angestoßen.

 

Nun kommts:

Die Replikation innerhalb des Praxis LAN und WLAN klappt hervorragend.

Die Replkation von einem anderen Standort aus über VPN zwischen 2 Fritzboxen 7490 funktioniert nicht. Habe alternativ den Shrew Soft VPN Client probiert, geht ebenfalls nicht.

Serverzugriff der Software vom Client aus ist sehr langsam, aber stabil, d.h. die Praxissoftware kann auf den Server über VPN (langsam) zugreifen, aber über den gleichen VPN Zugriff ist die merge-replikation nicht möglich.

 

Kann es sein, dass die merge-Replikation als Funktion des SQL-Servers andere Portfreigaben oder Firewall-Freigaben benötigt als der "einfache" Severzugriff über VPN?

 

Netzanbindung in der Praxis ist DSL mit 10 MBit/s im Download und 1 MBit/s im Upload. Im Home Office habe ich DSL mit 35 Mbit im Download und 9 MBit im Upload.

 

Nun  überlege ich den SQL-Server so zu konfigurieren, dass ich die Geschwindigkeit für die Replikation auf 1 MBit/s begrenze bzw. fest einstelle. Möfglicherweise hat der SQL Server bei der Replikation ja Probleme mit asymmetrischen Verbidungen. Gibt es dafür Einstellungen beim SQL Server?. Ich habe nix diesbezügliches im Netz gefunden.

 

Die Alternative, DSL in der Praxis upzugraden, ist nicht realisierbar; Netcologne will für einen 10/10 DSL Anschluss mit fester IP mehr als 300 EUR je Monat haben.

 

Vielleicht hat ja einer von Euch eine Idee, wie man die Replikation noch hinkriegen könnte.

 

Schon mal vielen dank für alle Hinweise

 

Gerd

bearbeitet 11. November 2017 von gerd33

[monstermania 53]

Hmm,

'geht nicht' ist natürlich ein toller Ansatzpunkt!  :rolleyes:

 

Welche Fehlermeldung gibt es denn (Log-Dateien)?

Logs auf den SQL-Server ausgwertet?

VPN-Logs ausgewertet? 

Schon mal darauf geprüft, ob evtl. ein Timeoutfehler vorliegt?

 

Gruß

Dirk

[testperson 1.675]

Hi,

 

warum nicht "einfach" per RDP auf einen Client / Terminalserver in der Praxis zugreifen und glücklich sein?

 

Gruß

Jan

[gerd33 18]

RDP geht nicht, da ich offline arbeiten muss. Da, wo ich beim Kunden bin, gibts nur langsamstes Internet. Die Offline-Arbeit an der Replikation geht hingegen schnell wie im LAN.

 

Timeout -Problem glaube ich auch nicht:

Habe Verbindungs-Timeout auf 120 s und Ausführungs-Timeout auf 15 s eingestellt.

 

Werde den Hersteller der Anwendung (SAMAS, arbeitsmedizinische Software) mal befragen, welche Befehlssequenz beim Betätigen der Schaltfläche "synchronisieren" an den SQL-Server gegeben wird. Müsste mir danach mal die Fehlermeldungen des SQL-Servers ansehen.

 

Habe einige Replikationswarnungen gefunden: s. nachstehend.

Könnte evtl. etwas mit dem Problem zu tun haben?

 

[Replikationswarnung: Langer Zusammenführungsvorgang über DFÜ-Verbindung (Schwellenwert: mergeslowrunduration)]

[Replikationswarnung: Langer Zusammenführungsvorgang über LAN-Verbindung (Schwellenwert: mergefastrunduration)]

[Replikationswarnung: Langsamer Zusammenführungsvorgang über DFÜ-Verbindung (Schwellenwert: mergeslowrunspeed)]

[Replikationswarnung: Langsamer Zusammenführungsvorgang über LAN-Verbindung (Schwellenwert: mergefastrunspeed)]

[Replikationswarnung: Transaktionsreplikations-Latenzzeit (Schwellenwert: latency)]

 

 

Kann man da irgendwie ein Timeout erhöhen??

bearbeitet 15. November 2017 von gerd33

[mwiederkehr 373]

Evtl. ein MTU-Problem? Ist auf den Firewalls eine Option "ignore DF bit on VPN connections" oder ähnlich gesetzt?

 

Hatte schon ähnliche Phänomene bei Scan2Folder über VPN: Ping ging, Dateien auflisten auch, aber es wurden nur leere Dateien erstellt. Da war es ein MTU-Problem.

[gerd33 18]

Habe beide Firewalls (Server + Client) mal abgeschaltet; Problem besteht weiterhin.

 

Habe gestern allerdings einen Kollegen getroffen, der die gleiche SW verwendet und zwischen 2 Standorten problemlos replizieren kann. Verwendet aber an seinen (ebenfalls langsamen ) DSL Anschlüssen jeweils einen Lancom Router mit integriertem VDSL-Anschluss. Dort läuft es stabil, aber langsam. Hat ihm sein IT-Dienstleister so eingerichtet.

Denke mal, dass das Problem an den VPN-Verbindungen meiner Fritz-Boxen liegen wird. MTU kann ich da z.B. gar nicht konfigurieren.

 

Werde mal andere Router probieren; wenns nix gibt, kann man die ja in OVP innerhalb von 2 Wo wieder eintauschen.

[gerd33 18]

Habe mal die Fehlerprotokolle aus dem Replikationsmonitor des Servers kopiert:

 

Fehlermeldungen:
Der Prozess konnte keine Verbindung mit Subscriber 'NOTEBOOK-I3\SQLEXPRESS' herstellen. (Quelle: MSSQL_REPL, Fehlernummer: MSSQL_REPL20084)
Hilfe abrufen: http://help/MSSQL_REPL20084
SQL Server-Netzwerkschnittstellen: Fehler beim Suchen des angegebenen Servers/der angegebenen Instanz [xFFFFFFFF].  (Quelle: MSSQLServer, Fehlernummer: -1)
Hilfe abrufen: http://help/-1
Netzwerkbezogener oder instanzspezifischer Fehler beim Herstellen einer Verbindung mit SQL Server. Der Server wurde nicht gefunden, oder auf ihn kann nicht zugegriffen werden. Überprüfen Sie, ob der Instanzname richtig ist und ob SQL Server Remoteverbindungen zulässt. Weitere Informationen erhalten Sie in der SQL Server-Onlinedokumentation. (Quelle: MSSQLServer, Fehlernummer: -1)
Hilfe abrufen: http://help/-1
Abfragetimeout abgelaufen. Fehlerhafter Befehl:  (Quelle: MSSQLServer, Fehlernummer: 0)
Hilfe abrufen: http://help/0
Vom Mergeprozess konnte eine Abfrage nicht ausgeführt werden, da für die Abfrage ein Timeout aufgetreten ist. Falls dieser Fehler weiterhin auftritt, erhöhen Sie das Abfragetimeout für den Prozess. Führen Sie zur Problembehandlung einen Neustart der Synchronisierung mit ausführlicher Verlaufsprotokollierung aus, und geben Sie eine Ausgabedatei an, in die geschrieben werden soll. (Quelle: MSSQLServer, Fehlernummer: 0)
Hilfe abrufen: http://help/0
Das Abonnement für die SAmAsSQL-merge-Veröffentlichung konnte nicht überprüft werden. Stellen Sie sicher, dass alle Merge-Agent-Befehlszeilenparameter ordnungsgemäß angegeben sind und dass das Abonnement ordnungsgemäß konfiguriert ist. Falls der Verleger keine Informationen mehr zu diesem Abonnement hat, löschen Sie das Abonnement, und erstellen Sie es erneut.  (Quelle: MSSQL_REPL, Fehlernummer: MSSQL_REPL-2147201019)
Hilfe abrufen: http://help/MSSQL_REPL-2147201019

 

 

Wie gesagt: Fehler kommen nur bei der merge-Replikation per VPN. PerLAN läufts fehlerfrei durch.

 

Hat jemand eine Idee?? Der IT-ler sagte, dass die FritzBox unproblematisch sei.

[zahni 554]

Ich miene, die Fritzbox filtert per default einige Ports. Schaue  Dir mal die Konfig an. Das kann man irgendwo ausstellen. Mir fällt leider gerade nicht  ein wo...

[testperson 1.675]

Ich würde darauf tippen, dass es am DNS scheitert.

Nutze am Client im Remote Standort mal den DNS Server aus der Praxis. Der Client ist in der Domäne?

[gerd33 18]

Habe kein Domänenbasiertes Netz. Lediglich 3 IP-Kreise (192.168.0.x - 192.168.178.x - 192.168.17.x) mit gemeinsamer Subnet-Maske (255.255.255.0), die über VPN permanent verbunden sind

 

Zugriff auf freigegebene Netzlaufwerke bzw. -ordner funktioniert per IP-Zuweisung. (z.B. "P" ist 192.168.178.55/"Verzeichnisname")

 

Zugriff der Anwendungssoftware des Clients (192.168.178.x) auf den SQL-Server (192.168.0.x) funktioniert ebenso, d.h. ich kann mit dem Client über VPN zwar arbeiten, aber nicht über VPN replizieren. Oder benutzt die Replikation andere Ports bzw. Freigaben als der "normale" SQL-Serverzugriff?

Die Ports 1433 / 1434 sind in der Fritzbox nicht explizit freigegeben, da der Serverzugriff auch so funktioniert. Oder kann das schon die Lösung sein?? Habe lediglich in der Software-FW (Windows bzw. GData) die Anwendung Sqlservr bzw sqlbrowser freigegeben.

[zahni 554]

Du  hast  offenbar eine Menge Arbeit vor Dir. Ich würde  die alles von Grundauf überarbeiten. Namensauflösung  richtig einrichten, Domäne schadet auch nicht.

Wie Du an den FMs siehts, versuchen div. Dienste eine Namensauflösung die  scheitert. Es gibt schon heute Dienste (z.B. SSL und Kerberos) die ohne  eine Namensauflösung  nicht  funktionieren.

[monstermania 53]

@gerd33

Um zu prüfen, ob es an der fehlenden DNS-Auflösung liegt könntest Du testweise einfach mal die HOST Datei auf dem Sync-Client anpassen.

Wenn die Synchronisiation mit angepasster HOST Datei dann per VPN klappt liegt es definitiv an der fehlenden DNS-Auflösung.

[gerd33 18]

@monstermania

 

Hosts Eintrag auf client ist

 

192.168.0.100     server

 

d.h. die sql-Anwendung meldt sich bei server/samas an und man kann arbeiten, aber nicht replizieren.

Habe in beiden Fritzboxen Port 1433 -TCP und Port 1434 -UDP freigegeben; das war auch nicht die Ursache
 

[testperson 1.675]

Schön, dass der Client den Server jetzt "auflösen" kann. In der o.g. Fehlermeldung möchte aber der Server vermutlich den Namen vom Client (NOTEBOOK-I3) auflösen.

 

Du baust dir hier eine Würgaround-Krücke nach der anderen. Dann noch "Praxis", "Fritzbox", "Daten", "Notebook", ... Mach es doch einfach vernünftig, auch wenn es ein paar Mark kostet!

[gerd33 18]

@testperson

 

Das Notebook sollte an mehreren Orten replizieren können. Bekommt in der Praxis z.B. eine IP der Art 192.168.0.x, aber zu Hause 192.168.178.x, jeweils per dhcp.

 

Oder könnte ich in der hosts-datei mehrere Einträge für denselben Namen eintragen? z. B

 

 

192.168.178.5                Notebook-I3

192.168.0.75                 Notebook-I3

 

 

Der zweite Hinweis mit den "paar Mark" ist OK; aber ich kenne bislang kein ordentliches Systemhaus im Raum südliches Köln / rechtsrhein. Rhein-Sieg-Kreis, die ich als "gut" bezeichnen könnte. Wäre diesbezüglich für einen Tipp aus dem Forum dankbar.

 

Einen anderen Hinweis aus einem vorigen Kommentar, ein domänenbasiertes Netz einzurichten, sehe ich kritisch. Was mache ich, wenn der DC nur über VPN erreichbar ist (Haupt-Server steht in der Praxis) und Internet mal wieder ausfällt? Kommt gelegentlich hier vor.