MS SQL Server Instanz nicht über VPN-Tunnel zu öffnen

[magicpeter 13]

Moin,

 

wir haben einen Kunden mit 2 Standorten und auf jedem Standort läuft ein MS SQL Server 2019. Beide Standorte sind mit einem permanenten VPN-Tunnel verbunden. Der Hersteller der Warenwirtschaft möchte jetzt von Standort A auf die MS SQL Datenbank von Standort B zugreifen.

Haltet ihr das für eine gute Idee?

Besser wäre doch wenn jeder Standort sein autarkes System mit allen Datenbanken hätte und dann nur per Terminalserver die entsprechende Warenwirtschaft geöffnet werden würde.

Edited April 15 by magicpeter

[v-rtc 92]

Moin. Kommt auf die Faktoren an… Wie ist denn die Anbindung usw und was soll wie und wann abgefragt werden… was ist es denn für eine Software?

[magicpeter 13]

vor 3 Minuten schrieb v-rtc:

Moin. Kommt auf die Faktoren an… Wie ist denn die Anbindung usw und was soll wie und wann abgefragt werden… was ist es denn für eine Software?

Die Anbindung ist eine DSL-Verbindung mit 100 MBit Download und 30 MBit Upload.

Es handelt isch um eine Warenwirtschaft mit Rechnungswesen und das Rechnungswesen liegt auf Standort B uns soll regelmäßig von Standrot A abgefragt werden.

 

Wir hatten jetzt schon Probleme von Standort A mit Microsoft SQL Server Management Studio 18 die Datenbank an Standort B zu öffnen.

"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. (provider: Named Pipes Provider, error: 40 - Verbindung mit SQL Server konnte nicht geöffnet werden) (.Net SqlClient Data Provider)"

 

FQDN\instanzname

serversql1.domain.local\FIBU

 

Damit der FQDN über den VPNTunnel richtig aufgelöst werden kann haben wir den FQDN in die dazugehörige IP-Adresse in der Hosts-Datei gespeichert.

 

Per ping lässt sich der Server erreichen.

 

Nur nicht per Microsoft SQL Server Management Studio 18

 

[t-sql 22]

Hallo @magicpeter,

1. die Anbindung für so ein Vorhaben ist ein Witz. Da brauchste schon eine synchrone Anbindung,

2. die Verbindung zum SQL Server über VPN ist kein Problem. Verbindungsprobleme dabei sind nur Netzwerkprobleme und hat mit SQL Server nix zu tun,

3. Nimmst du TCP/IP und nicht Named Pipes als Provider,

4. brauchste dir bei der Anbindung keine Hoffnung auf Performance zu machen,

5. ist mir klar, das der Kunde kein Geld in die Hand nehmen will um das gscheit zu machen.

 

Sind die beiden Standorte völlig unabhängig von einander oder ist die WW für beide Standorte gedacht?

[magicpeter 13]

vor 14 Stunden schrieb t-sql:

Hallo @magicpeter,

1. die Anbindung für so ein Vorhaben ist ein Witz. Da brauchste schon eine synchrone Anbindung,

Also macht das keinen Sinn das per VPN-Tunnel performant zu realisieren. Das habe ich mir schon gedacht.

 

vor 14 Stunden schrieb t-sql:

2. die Verbindung zum SQL Server über VPN ist kein Problem. Verbindungsprobleme dabei sind nur Netzwerkprobleme und hat mit SQL Server nix zu tun,

3. Nimmst du TCP/IP und nicht Named Pipes als Provider,

4. brauchste dir bei der Anbindung keine Hoffnung auf Performance zu machen,

5. ist mir klar, das der Kunde kein Geld in die Hand nehmen will um das gscheit zu machen.

 

Sind die beiden Standorte völlig unabhängig von einander oder ist die WW für beide Standorte gedacht?

 

Der Kunde wird jetzt an jedem Standort alle Datenbanken vorhalten um nicht über den VPN-Tunnel zu müssen.

 

Das ist auf jeden Fall der bessere und performantere Weg.

 

 

[NorbertFe 2,197]

vor 28 Minuten schrieb magicpeter:

Also macht das keinen Sinn das per VPN-Tunnel performant zu realisieren.

Klar, nur dann eben performante Leitung. ;)

[magicpeter 13]

vor 1 Stunde schrieb NorbertFe:

Klar, nur dann eben performante Leitung. ;)

Woher willst du denn so eine Performance Leitung bekommen?

 

Und was muss die können?

[Dukel 465]

Gerade eben schrieb magicpeter:

Woher willst du denn so eine Performance Leitung bekommen?

 

Und was muss die können?

 

Das kommt auf die Anforderungen der Applikation an ;)

[NorbertFe 2,197]

vor 2 Minuten schrieb magicpeter:

Woher willst du denn so eine Performance Leitung bekommen?

 

Es soll Anbieter geben, die vermieten einem das bei Einwurf entsprechender Münzen. Wir haben hier bspw. 2x 1GBit/s (symmetrisch) im Haus.

 

vor 3 Minuten schrieb magicpeter:

Und was muss die können?

Sie muss schnell sein.

 

 

[Dukel 465]

vor 12 Minuten schrieb NorbertFe:

Sie muss schnell sein.

Zur Ergänzung: Bei "Schnell" ist die Bandbreite UND Latenz gemeint.

Aber wie schon geschrieben sollte der Hersteller der Applikation diese Anforderungen benennen können.

[mwiederkehr 391]

Es kommt ganz auf die Anwendung an. Ich habe schon mehrere Leute zufrieden über eine Leitung mit 20 MBit/s Upload arbeiten gesehen. Es ist ein grosser Unterschied, ob eine Anwendung beim Aufruf der Kundenübersicht alle Kunden lädt oder nur so viele, wie auf den Bildschirm passen. Wenn der Hersteller keine genauen Angaben macht, hilft nur ein eigener Test.

[t-sql 22]

vor 9 Stunden schrieb magicpeter:

Der Kunde wird jetzt an jedem Standort alle Datenbanken vorhalten um nicht über den VPN-Tunnel zu müssen.

 

Das ist auf jeden Fall der bessere und performantere Weg.

 

 

Müssen denn die Datenbanken nicht synchron gehalten werden?
 

vor 7 Stunden schrieb magicpeter:

Woher willst du denn so eine Performance Leitung bekommen?

 

Und was muss die können?

 

Hier kannste mal anfragen DeutschlandLAN Connect IP | Telekom Geschäftskunden. 

[magicpeter 13]

vor 23 Stunden schrieb t-sql:

Müssen denn die Datenbanken nicht synchron gehalten werden?

 

 

Nein, jeder Standort hat seine eigene Warenwirtschaft. Hier sind das unterschiedliche Firmen die nur den gleiche Chef haben ;) 

 

vor 23 Stunden schrieb t-sql:

 

 

 

 

Hier kannste mal anfragen DeutschlandLAN Connect IP | Telekom Geschäftskunden. 

OK, danke.

 

Aber, da jeder Standort jetzt alle Datenbanken bekommt ist das nicht mehr notwendig.