|
We have a handful of customers that will not open up ports in their firewall to allow retrival / sending sql remote messages via FTP. Question 1: Is there a simple pitch that we can give these customers to open a port? I would guess that ports are open for retrival of such things as virus definitions. Question 2: Is there a real risk to our customers security wise if we can assume that our FTP server is "safe" Question 3: In the newer versions of SQL Remote the HTML transport is available. Is it complicated to switch from FTP to HTML? Can the system be mixed where most users still use FTP and the handful that block FTP can use HTML? Question 4: What is the Performance of HTML vs FTP? Lets say I need to send 1000 messages to 2000 remote databases. Can a server process 2 million plus messages in a reasonable amount of time. We are using the latest version 12 release of SQL Anywhere / Sql Remote. Thanks |
|
The HTTP support was put in an EBF, and never made it into the documentation -- UNTIL we updated it as part of the SA OnDemand release. Nevertheless, there indeed appear to be some omissions. I have contacted the documentation team about that. Meanwhile, you can find a useful tutorial here: http://dcx.sybase.com/index.html#1201/en/sqlremote/sra-tutorial-http.html Q1: We're run across many IT departments unwilling to open a port up, hence our creation of the Outbound Enabler (OE) that works with the Relay Server to allow incoming traffic without requiring IT begging and/or heroics. Some customers will open a port, but they require a reverse proxy, often one enhanced with intrusion detection and such. HTTP is likely to be the ONLY inbound traffic supported in the majority of these cases, not FTP. Q2: Assumptions are scary. FTP would provide file access inside the firewall, and permissions must be managed VERY carefully. It really depends on the IT department involved, but I expect most won't go for it. The Relay Server avoids the problem nicely. Q3: See Breck's answer. Q4: In our performance tests, HTTP was comparable to FILE. Larger message "files", which map to HTTP requests, should give better performance, but you should do your own performance testing to find the sweet spot that works best for you under expected loads. Just to add: As to a setup with a relay server on the consolidated database "site", cf. this tutorial, too:
(14 Jul '12, 05:03)
Volker Barth
|
|
Q3) It should be very easy to switch the message type from FTP to HTTP/HTTPS. Please replicate all the messages for the remote users you would like to change, before switching the message type. Otherwise you may have to manually copy the messages from the directories in the FTP setting to that in the HTTP/HTTPS setting. It should be no problem to have a mixed setting. But you should test it in your test environment before put it in production. Q4) To get better performance, you may need to have a dedicated message server on a decent machine, instead of using the consolidated database server as a message server. |
Message type HTTP is so new, the docs haven't been entirely updated; for example GRANT REMOTE only mentions FTP, FILE and SMTP: http://dcx.sybase.com/index.html#1201/en/dbreference/grant-remote-statement.html
However, HTTP does exist, and there is even an https=yes parameter which sounds ideal for you: http://dcx.sybase.com/index.html#1201/en/sqlremote/sr-http.html
For the most part, I guess you will have to find out for yourself if the switch to HTTP(S) is affordable in both your configuration tasks and in performance.
AFAIK, the consolidated can use different message types for different users, so running FTP and HTTP(S) in parallel should work. Note that the consolidated uses a FILE message type when the remotes use HTTP(S).
FWIW, we have developped our own HTTPS transport for files shared with a FILE type, simply as FTP seemed not secure enough. That was long before the builtin HTTP(S) message type was offered, so I don't have actual information on the new HTTP(S) message system performance.