Zugriff via VPN auf Datenbankserver
Sascha Lammers
ich habe jetzt alle Threads des letzten 3/4 Jahres in diesem Forums
durchgesucht, aber bei den Postings zu dem Thema Verbindungen via VPN oder
Terminalserver nichts gefunden was mir weiterhilft.
Im Prinzip ist mein Anliegen ja auch nicht neu, aber es fluppt nun mal nicht
:-( Über Hilfe wäre ich sehr dankbar, auch wenn es ein Link zu einem
bestehenden Posting oder einer Webseite ist.
Ich habe eine funktionierende VPN-Verbindung von einem WinXP Pro Rechner
über das Internet in ein kleines Firmennetzwerk, in dem ein DrayTek Vigor
2600X Router die Verbindung ins Netz herstellt und auch gleichzeitig der VPN
Server ist. Bei der Verbindung bekomme eine IP-Adresse aus dem lokalen
IP-Pool zugewiesen, ich finde alle Rechner incl. Lexware Server (ebenfalls
WinXP) in der Netzwerkumgebung, kann auf die freigegebenen Shares zugreifen
und kann alle Rechner pingen (beide Richtungen). Die Rechner im "echten"
lokalen Netzwerk können auch ganz normal auf die Lexware Datenbank (LFO2003)
zugreifen.
Daraufhin habe ich eine Installation auf dem Client durchgeführt, der via
VPN auf den Lexware Server zugreifen soll. Hat zwar knapp 2 Stunden über DSL
gedauert, hat aber einwandfrei funktioniert. Aber beim Start des Clients
bekomme ich die bereits vielfach in diesem Forum zitierte Fehlermeldung:
"Fehler bei der Verbindung zum Datenbankserver DSN: <LXSYDSN> aufgetreten...
usw.".
Ich habe sowohl am Server als auch beim Client in den ODBC-Datenquellen das
Netzwerkprotokoll auf TCP/IP eingestellt, aber mehr fällt mir nicht ein.
In einem Thread wurde gesagt, dass das mit dem VPN ganz einfach sei. Wo ist
der "Denk-"Fehler?
Vielen Dank
Sascha Lammers
Ulrich Abel
>
>Hallo Herr Lammers,
>
Bemerke gerade, das wir uns in der falschen newsgroup bewegen.
Dies gehört wohl eher in die technik.
Ich weiss nicht, ob das jemand beheben kann.
Mit freundlichen Grüßen aus Hannover
Ulrich Abel
Ulrich Abel
<slam...@bigfoot.de> wrote:
>Hallo,
>
>ich habe jetzt alle Threads des letzten 3/4 Jahres in diesem Forums
>durchgesucht, aber bei den Postings zu dem Thema Verbindungen via VPN oder
>Terminalserver nichts gefunden was mir weiterhilft.
> ...
>
>In einem Thread wurde gesagt, dass das mit dem VPN ganz einfach sei. Wo ist
>der "Denk-"Fehler?
>
>Vielen Dank
>
>Sascha Lammers
>
Hallo Herr Lammers,
soweit ich mich erinnern kann, soll Lexware für Ihren Lösungsansatz
nicht besonders gut geeignet sein. (Zuviel Traffic bei DB-Zugriff)
Auf der anderen Seite würde es mich sehr interessieren ob es nicht
evtl doch teilweise gut funktioniert. Sozusagen als Alternative zum
Terminal-Server.
Wenn Sie mir versprechen, mich über den Erfolg Ihrer Bemühungen auf
dem laufenden zu halten ( sonst bitte nicht weiterlesen), stelle ich
Ihnen im folgenden die Bemühungen meiner Kurzrecherche zur Verfügung.
Alle aus der Sybase Newsgroup:
<schnipp>
On your client, you may need:
links=tcpip(host=xxx.xxx.xxx.xxx;dobroad=none)
This avoids using UDP broadcasts which may be blocked by a firewall.
If you
are using an ODBC DSN, put host=xxx.xxx.xxx.xxx;dobroad=none in the
edit box
beside the TCP/IP check box in when configuring the ODBC Data Source.
xxx.xxx.xxx.xxx is the IP address of the machine where the ASA server
is
running, and the IP hostname can also be used.
--
Ian McHardy (iAnywhere Solutions)
I have a client who is using Sybase Adaptive Server Anywhere v6.0.4
with a
third Party Software. When three of his staff access the third Party
software, they suffer from really slow performance. They are
connecting via
DSL. If there are few using the LAN with the software, their
performance
is great. What I would like to know is what or who is the data sent
and
data recived speed so that we can increase the bandwith? Also, what
recommendations would you make to increase performance from the client
to
the server? Thank you, Joanna
Hi There
Could you tell me where can I get more information how to install an
SQLAnywhere client via VPN.
We are using SQLAnywhere 7.0.4.2788. and connect our application via
ODBC.
We have two sites which we need to connect over VPN.
Do we need to install additional Tools like mobile link? If yes where
do I
get best help to setup Mobile link?
Thank you for help
Juerg Caluori
Add HOST to your connection parameter. HOST should be set to the
machine
name or IP of the machine hosting the database engine.
We have a number of clients using what Chris suggests and it works
fine on
either a VPN or a WAN
try the commlinks settings in the DSN
commlinks=TCPIP{HOST=IP Adress;DOBROADCAST=NONE}
It's very common that UDP packets are filtered in a VPN, hence a
broadcast
won't go thru.
--
Guido Farrenberg
Sybase Certified Professional ASA Developer
<schnapp>
Obige Erkenntnisse müssten unter :
verwaltung/datenquellen/system-dsn/lxsydsn/ in die Reiter
Datenbank,Netzwerk,Erweitert eingearbeitet werden.
Dann sollte es gehen.
Sascha Lammers
zuerst einmal vielen Dank für die prompte Antwort. Der Eintrag "host=..."
war der Schlüssel der es mir nun überhaupt erstmal ermöglicht auf die
Datenbank zuzugreifen. So weit, so gut, aber es gibt dann doch noch einige
Wehrmutstropfen an denen es noch zu arbeiten gilt:
Der Zugriff ist tatsächlich sehr langsam. Z.B. dauert es nach einem Klick
auf die Kundendatei ca. 35 Sekunden, bis die etwa 12.000 Kunden
aufgelistet werden und man weiterarbeiten kann. Jeder Aufruf einer
Funktion dauert mehrere Sekunden, sodaß sich das Programm noch sehr träge
anfühlt. Auch das Feedback darüber, ob ich einen Button geklickt habe oder
nicht, dauert sehr lange. Via RDP (oder Terminalserver) ist das wesentlich
angenehmer.
Was mich ebenfalls wundert ist, dass die Übertragungsrate bei
Datenbankzugriffen am Netzadapter mit ca. 6kb/s nicht einmal die Hälfte
der verfügbaren Bandbreite nutzt. Auch da muss ich wohl noch etwas
rumprobieren.
Systeminfos:
Server: WinXP, Athlon 1800+, 512MB, 80GB7200rpm, T-DSL (768down,128up,
kein Fastpath), Router DrayTek 2600X, LFO2003 SP1
Client: WinXP, 2.4P4, 512MB, NetDSL (1Mdown, 128up, Fastpath), SuSE-Linux
Router
Der Ping liegt bei durchschnittlich 85ms. Aus Erfahrung weiß ich das
Fastpath und damit mögliche Pings <20ms für RDP und
Terminalserververbindungen von Vorteil sind. Ob das für einen
Datenbankzugriff auch relevant ist kann ich noch nicht sagen. Kann diese
Frage vielleicht jemand beantworten?
Weiterhin funktioniert die u.g. Option "dobroad=none" bzw.
"DOBROADCAST=NONE" nicht. Sobald ich diese Option wie angegeben zu der
Host-Option hinzufüge, bekomme ich keine Verbindung zum Datenbankserver.
Das Logfile sieht dabei wie folgt aus:
[...]
Sam Dez 06 2003 15:55
de: CONN: Application information:
"HOST=SHUTTLE;OS=Windows
2000;PID=0x1f40;THREAD=0x2674;EXE=C:\Programme\Lexware\Gemeinsame
Dateien\Framework\Framework.exe;VERSION=7.0.1.1150;API=ODBC"
CONN: Verbindung mit Standard-DSN wird versucht. Benutzt wird:
UID=_login_;PWD=****************;ENG=192.168.1.101;CON=SQL_DBC_1154a68;ASTOP=YES;INT=NO;DBG=YES;LOG=d:\lexwareLOG.txt;DMRF=NO;LINKS=TCPIP{host=192.168.1.101;dobroad=none}
Start der TCPIP-Verbindung wird versucht ...
Fehler beim Analysieren der gelieferten Optionen - TCP/IP
Unzulässiger Wert für die Option "DoBroadcast"
TCPIP Verbindung nicht gestartet
Fehler in den TCPIP Portoptionen
CONN: Verbindung kann nicht hergestellt werden
[...]
Soweit erstmal meine ersten Infos zu diesem Thema. Wer noch weitere Tipps
hat
--
Sascha Lammers
Sascha Lammers
geschrieben:
Hoppala! Hatte gar nicht nachgeschaut ob es ein solches Forum auf diesem
Newsserver gibt. Muss gleich mal schauen.
--
Sascha Lammers
Klaus P. Pieper
[...]
>
> Soweit erstmal meine ersten Infos zu diesem Thema. Wer noch weitere
> Tipps hat
Es wird langsam bleiben. Das hat nichts mit der Datenbank zu tun, sondern
damit, dass bei Lexware nun einmal sehr viele Daten über's Netz
transportiert werden, die eigentlich schon in der Datenbank selbst gefiltert
werden könnten. Für DSL und ähnlich "langsame" Netze in der jetzigen Version
einfach nicht geeignet. Höchstens mit einem Terminal-Server oder
Remote-Replikation (wir arbeiten noch daran), aber das ist auch (wie auch
der Zugriff mit einem VPN) schon mehrfach im Technik-Forum besprochen
worden.
Gruß
Klaus
--
Die email Adresse (reply-to) im header ist ungueltig.
Fuer mail "pub . kp2 . pieper @ ibeq . com" benutzen.
(Leerzeichen loeschen).
Reply-to invalid.
Use "pub . kp2 . pieper @ ibeq . com" (remove spaces).
Christian Kupka
muß mich mal einklinken.
VPN via DSL ist m.E. (zumindest für den vorgesehenen Zweck) nicht brauchbar.
Die mögliche Rate beim Upstream erreicht in den seltensten Fällen (nach
meiner bescheidenen Erfahrung) die angegebenen Werte.
Denn durch den (nötigen) Transfer der Daten durch diesen Flaschenhals wird
kein vernünftiges arbeiten möglich sein. Es sei denn man verfügt über eine
Verbindung mit mindestens 2MBit in beiden Richtungen.
Sinnvoll scheint die verwendete Energie in die Teminalserverlösung zu
stecken. Denn hier wird die Arbeit auf dem Terminalserver verrichtet und
lediglich (ist aber auch schon genug) grafische Ausgaben werden durch den
Flaschenhals gezwängt.
Ich habe leider selbst keine Zeit eine Testumgebung aufzubauen um selbiges
Szenario zu testen. Einer vernünftigen Funktion der Lösung sollte nichts
entgegensprechen - auch wenn LEXWARE das nicht empfiehlt. Wahrscheinlich
aus Übervorsichtigkeit. Letztendlich liegt die Verantwortung beim Anwender
einer solchen Lösung.
Sollten Anwender hier Forum aber damit praktische Erfahrungen haben/erlangen
würde ich gerne davon profitieren.
MfG
Christian Kupka
Sascha Lammers
geschrieben:
> Sascha Lammers wrote:
> [...]
>
>>
>> Soweit erstmal meine ersten Infos zu diesem Thema. Wer noch weitere
>> Tipps hat
>
> Es wird langsam bleiben. Das hat nichts mit der Datenbank zu tun, sondern
> damit, dass bei Lexware nun einmal sehr viele Daten über's Netz
> transportiert werden, die eigentlich schon in der Datenbank selbst
> gefiltert
> werden könnten. Für DSL und ähnlich "langsame" Netze in der jetzigen
> Version
> einfach nicht geeignet. Höchstens mit einem Terminal-Server oder
> Remote-Replikation (wir arbeiten noch daran), aber das ist auch (wie auch
> der Zugriff mit einem VPN) schon mehrfach im Technik-Forum besprochen
> worden.
>
> Gruß
>
> Klaus
>
Hallo Klaus,
danke für die Infos. Das mit der Geschwindigkeit habe ich befürchtet.
Auch möchte ich mich dafür entschuldigen, dass ich diesen Thread in diesem
Forum aufgemacht habe. "lexnews.software.pro.technik" habe ich gestern
schlichtweg übersehen, und deshalb auch nicht dort nach bereits geposteten
Threads gesucht.
--
Sascha Lammers
Ulrich Abel
<slam...@bigfoot.de> wrote:
>Hallo Herr Abel,
>
>zuerst einmal vielen Dank für die prompte Antwort. Der Eintrag "host=..."
>war der Schlüssel der es mir nun überhaupt erstmal ermöglicht auf die
>Datenbank zuzugreifen.
war mir eine Freude
> So weit, so gut, aber es gibt dann doch noch einige
>Wehrmutstropfen an denen es noch zu arbeiten gilt:
nun wie ich bereits vermutete wirds wohl eine Sackgasse bleiben.
>Was mich ebenfalls wundert ist, dass die Übertragungsrate bei
>Datenbankzugriffen am Netzadapter mit ca. 6kb/s nicht einmal die Hälfte
>der verfügbaren Bandbreite nutzt. Auch da muss ich wohl noch etwas
>rumprobieren.
prima aber,
die Beobachtung, dass die Bandbreite nicht offensichtich mit der
Performance zusammenhängt, mussten wir auch bereits machen. (Zu Zeiten
als Lexware Sybase noch gar nicht verwendet hat)
Eine Vedopplung der Bandbreite hat nicht annähernd ein Verdopplung der
Performance gebracht
Erschwerend kommt hinzu, dass Sie als "Nichtentwickler" von Lexware
keinerlei Einflussmöglichkeiten auf eine Optimierung des
Datenbankzugriffs haben.
>Soweit erstmal meine ersten Infos zu diesem Thema. Wer noch weitere Tipps
>hat
z.B. von den Jungs mit der symmetrischen 2 MBit Leitung
Ulrich Abel
wrote:
>Remote-Replikation (wir arbeiten noch daran),
Hallo Herr Pieper,
das ist ja spannend
Ein solches Projekt hätte ich als noch aussichtsloser als das VPN
Projekt von Herrn Lammers eingestuft.
Würde mich sehr freuen, hier komplett auf dem Holzwege zu sein.
Bitte halten Sie uns (mich) unbedingt auf dem laufenden.