From: Daniel Ivanov <sertys@supportivo.org>
Cc: netfilter@lists.netfilter.org
Subject: Re: Login load balancing
Date: Fri, 28 Apr 2006 13:36:50 +0300 [thread overview]
Message-ID: <4451F042.70103@supportivo.org> (raw)
In-Reply-To: <444FB608.10009@netzwerk.cc>
The last one is not the best solution, because of the fact that you rely
on randomness. I would suggest you take a more comprehensive approach.
As the machines are snmp enabled, you just have to write a custom
daemon, receiving on port 22 (ssh) as a front-end and check which
machine is most idle and dnat the user there, for the DNAT to be able to
work, you would have to send an RST packet back to the ssh client and
wait for it to reconnect to the already DNAT-ted machine. That would be
a working solution. As long as you don't wanna have millions of rules on
the redirecting machine, you just have to "count" the active logins(use
pam_script for example) and remove the rules as long as the last shell
quits. You would like to have all simultaneous logins on the same
machine, so you'll have to check on a new login if the user is still
there and put it on the same machine. Just think about the RST packet,
cause i think it's not the most elegant solution as long as the user
will get a "Connection closed by remote site" msg.
Mailings'AT'netzwerk.cc wrote:
> Drew Leske wrote:
>
>> Hi all,
>>
>> I'm looking for a solution (and I'm not afraid of devving one if
>> necessary)
>> to load-balance SSH logins over several mostly identical systems. So
>> far
>> the closest I have come is a solution using iptables, but I'm not
>> sure it
>> will work, and I may well be overlooking some other solution. Any ideas
>> would be appreciated. My research has so far turned up little.
>>
>> We have several systems that are, from a user's perspective, identical.
>> Their home directories are network mounted, libraries are
>> synchronised, and
>> so on, so they don't really care which system they log in to. Their
>> work on
>> these systems can be quite intensive and may consume quite a few
>> resources,
>> but must remain interactive (so a batch system running on a cluster
>> won't do
>> it).
>>
>> For the users it's a guessing game as to which of the machines they
>> should
>> log in to at any point. They may log in to the first and find it's
>> heavily
>> loaded, and so log in to another, until they find the best. A second
>> difficulty with this is the users have be aware of which machines are
>> available--and they are named, due to historical reasons, using a
>> non-contiguous numbering scheme.
>>
>> So instead of the users logging in to bob3, bob6 or bob8, I'd like
>> for them
>> to be able to simply log in to "bob" and be directed to the least-loaded
>> machine.
>>
>> Round-robining on the switch won't do it, because if one of the
>> systems is
>> absolutely pinned, every Nth login will still wind up there.
>>
>> Determining which machines are least loaded will not be a problem. The
>> metrics may be gathered using SNMP or some other means from the
>> participating hosts. The problem is entirely in the redirection from
>> 'bob'
>> to 'bob3', 'bob6', 'bob8'.
>>
>> Logins are exclusively through SSH. There is no need, and I don't
>> anticipate one (which means there will be some fantastic new request
>> coming
>> in tomorrow) to support other protocols in this manner.
>>
>> The only half-solution I have come up with so far is to define a
>> 'director'
>> box with the 'bob' alias, and then periodically grab load metrics
>> from the
>> participating hosts, determine of the 'bob's which is the least
>> loaded, and
>> then *cough* update a DNAT rule to redirect requests coming in for
>> 'bob' to
>> the least-loaded 'bobX'.
>>
>> The last part feels horky, and I'm not even sure it will work, since
>> later
>> packets coming in may be DNAT'ed to a different machine. Also, the
>> director
>> then routes all the packets for logins to all the boxes. I can't see
>> any
>> way to redirect the initial connection that won't cause all sorts of
>> problems with the client's firewalls.
>>
>> Any ideas?
>>
>> Thanks,
>> Drew.
>>
> Hi Drew,
>
> maybe you should take a look on "iptables random" - target.
>
> Something like
>
> iptables -t nat -A PREROUTING -p tcp --dport 22 -i $whatever \
> -m random --average $[100/$howmuchserveryouvegot] \
> -j DNAT --to $server1
>
> iptables -t nat -A PREROUTING -p tcp --dport 22 -i $whatever \
> -m random --average $[100/$howmuchserveryouvegot] \
> -j DNAT --to $server2
>
> ...
>
> Only one idea, but remember "the last rule should realy match" ;-)
>
> Hope this is the right syntax.
>
> Best
>
> Sven
>
next prev parent reply other threads:[~2006-04-28 10:36 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-04-26 17:33 Login load balancing Drew Leske
2006-04-26 18:03 ` Mailings'AT'netzwerk.cc
2006-04-28 10:36 ` Daniel Ivanov [this message]
2006-04-28 16:54 ` Drew Leske
2006-04-26 18:20 ` Pablo Sanchez
2006-04-26 18:40 ` Drew Leske
[not found] ` <1146073387.24375.74.camel@sehe-c4.berlin.teles.de>
2006-04-26 18:27 ` Drew Leske
2006-04-27 10:16 ` Arnt Karlsen
2006-04-27 17:34 ` Drew Leske
2006-04-28 10:00 ` Arnt Karlsen
2006-04-28 16:37 ` Drew Leske
2006-04-28 18:23 ` Arnt Karlsen
2006-04-28 18:36 ` Drew Leske
2006-04-30 9:51 ` Arnt Karlsen
2006-04-26 21:37 ` Carl-Daniel Hailfinger
2006-04-26 21:56 ` Drew Leske
2006-04-27 10:31 ` michael
2006-04-27 17:37 ` Drew Leske
2006-04-27 17:42 ` Drew Leske
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4451F042.70103@supportivo.org \
--to=sertys@supportivo.org \
--cc=netfilter@lists.netfilter.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.