Hello,
On 11 January 2018 at 16:36, Jonathan Matthews <cont...@jpluscplusm.com> wrote: > On 11 January 2018 at 00:03, Imam Toufique <techie...@gmail.com> wrote: >> So, I have everything in the listen section commented out: >> >> frontend main >> bind :2200 >> default_backend sftp >> timeout client 5d >> >> >> #listen stats >> # bind *:2200 >> # mode tcp >> # maxconn 2000 >> # option redis-check >> # retries 3 >> # option redispatch >> # balance roundrobin >> >> #use_backend sftp_server >> backend sftp >> balance roundrobin >> server web 10.0.15.21:2200 check weight 2 >> server nagios 10.0.15.15:2200 check weight 2 >> >> Is that what I need, right? > > I suspect you won't need to have your *backend*'s ports changed to > 2200. Your SSH server on those machines is *probably* also your SFTP > server That's exactly right, your backend destination port should probably 22, there is no need to bump that one to 2200. > As an aside, it's not clear why you're trying to do this. You've > already hit the host-key-changing problem, and unless you have a > *very* specific use case, your users will hit the "50% of the time I > connect, my files have gone away" problem soon. So you've probably got > to solve the shared-storage problem on your backends ... which turns > them in to stateless SFTP-to-FS servers. > > In my opinion adding haproxy as a TCP proxy in your architecture adds > very little, if anything. If I were you, I'd strongly consider just > sync'ing the same host key to each server, putting their IPs in a > low-TTL DNS record, and leaving haproxy out of the setup. With DNS round-robin instead of haproxy you have the same exact requirements regarding SSH keys and filesystem synchronization, with all the disadvantages (no health checks, no direct control of the actual load-balancing, no stats, no logs, etc). I'm really not sure why you'd recommend DNS RR instead of haproxy here. Load-balancing a single-port TCP protocol between 2 backends is a bread and butter use-case for haproxy. Regards, Lukas
