I wasn't able to make headway with ltsp-cluster, so we have taken a
different (simpler?) approach to load balancing / failover with LTSP,
which works well for us.
We have 2 LTSP servers. We have two floors of fat clients and we like to
have one floor boot off server 1 and the other boot off server 2, but
any booting client will fail over to the other server if it fails to
boot from its preferred server. There is no real-time transfer from one
server to another or anything fancy like that, (although this may be
achievable with virtual machines) - in our scenario, if a server dies
mid-session, the client is rebooted and boots off the other server.
We have 2 pfsense firewalls in failover configuration using CARP. We use
DHCP and network boot settings on pfsense to direct booting clients to a
custom ipxe script via TFTP, also located on the pfsense Firewalls
(there's a module). That takes care of redundant DHCP, TFTP and gateway
(and also handily supports failover WANs).
The ipxe script checks the client's MAC address and directs it to boot
off the preferred server; a list of MAC addresses have to be hardcoded
into the script and related to a specific server for this to work. If
booting fails at any point, the ipxe script sends it to the other
server. It looks like this:
#!ipxe
ifopen
:mac-check # MAC ADDRESSES MUST BE IN lower case!
iseq ${netX/mac} ac:22:0b:c5:9f:fb && goto server1 ||
#Floor1, PC1
iseq ${netX/mac} ac:22:0b:2b:df:e0 && goto server2 ||
#Floor 2, PC1
:server1
imgfree
echo Attempting to boot from Server 1
kernel tftp://192.168.1.11/ltsp/i386/vmlinuz root=/dev/nbd0
init=/sbin/init-ltsp vt.handoff=7 nbdroot=192.168.1.11:/opt/ltsp/amd64
|| goto server2
initrd tftp://192.168.1.11/ltsp/i386/initrd.img || goto server2
boot ||
:server2
imgfree
echo Attempting to boot from Server 2
kernel tftp://192.168.1.12/ltsp/i386/vmlinuz root=/dev/nbd0
init=/sbin/init-ltsp vt.handoff=7 nbdroot=192.168.1.12:/opt/ltsp/amd64
|| goto server1
initrd tftp://192.168.1.12/ltsp/i386/initrd.img || goto server1
boot || goto server1
(thanks to the ipxe IRC people for helping me out with that!)
This set up does not support identifying the least loaded server and
sending booting client to that server, but I am told this could be
achieved using ipxe's "dynamic scripting" (PHP script runs on web
server, collects CPU usage data, sends client to boot from least busy
server). We didn't need it as fat clients barely load the server, so we
didn't do it.
The two servers synchronize user information (passwd, group files etc.)
as well as home directories and the nbd root images using unison run by
a cron script every few minutes, so the maximum amount of data lost is
about 5 minutes if a server were to fail mid-session. A nice side-effect
is that unison also supports version control, so users can roll back old
versions of files.
This set up has limits in terms of storage scalability - shared
redundant network storage would make sense for 200 clients I suppose,
but we're ok with RAID 1 drives in each server for now. Aside from that,
I can't think of a reason why more servers could not be added as needed
using this method.
On Thursday, 21 August, 2014 05:37 PM, Jaskaran Singh Lamba wrote:
Good afternoon to all,
I am from India and we are planning to implement the LTSP for thin
clients in our
college labs.
We have around 200 thin clients and 5 powerful servers and we will be
using Edubuntu for the servers as it has LTSP packages in it.
Our requirement is to balance the load amongst the 5 servers i.e all
thin clients would be connected to all the servers and the request for
boot image should be smartly handled according to the load on the
servers i.e the load on all the servers be checked and then thin
client be assigned to the server with least load.
My question is that how can this be done?
Does LTSP has any built in feature to handle this kind of system?
Is the above written approach feasible?
--
Jaskaran Singh Lamba
Blog: http://lambajaskaran.wordpress.com/
------------------------------------------------------------------------------
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
_____________________________________________________________________
Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto:
https://lists.sourceforge.net/lists/listinfo/ltsp-discuss
For additional LTSP help, try #ltsp channel on irc.freenode.net
------------------------------------------------------------------------------
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
_____________________________________________________________________
Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto:
https://lists.sourceforge.net/lists/listinfo/ltsp-discuss
For additional LTSP help, try #ltsp channel on irc.freenode.net
