[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [K12OSN] New K12LTSP installation



http://lightfleet.com/?cat=11

when this technology gets to be FULLY developed and produced... it might cure some of the problems James lists below ;)

--Huck

James P. Kinney III wrote:
On Thu, 2008-06-19 at 10:44 +0530, Sudev Barar wrote:
2008/6/19 James P. Kinney III <jkinney localnetsolutions com>:
4.  Is there a good writeup on load sharing between two K12LTSP servers if we
decide to go a bit fancy?
Too much work to load balance with only 2 servers. Split the client list
with the network wiring and divide and conquer!
Not really, running two servers with dhcpd load balancing and failover
was relatively easy. There was link some where. If you want to try
this I will dig it up.

DHCP is not the real load that needs balancing. It's the application
serving. While the DHCP load balancing can be used to split the boot up
and ultimately the server each client run from can be set this way, the
application load balancing is the issue I'm most interested in and
currently working on.

Picture this scenario: Large school with 800 students and 5 LTSP
servers. Several classes are fully populated with clients and make
extensive use of the heavy applications. Other classes do lighter stuff.
The teachers in the heavy use room will see the LTSP as slow. If there
is a way to dynamically shift the workload between running server so a
single server doesn't bog down under a classroom activity while others
are barely in use, that's a huge improvement.

This process is very technically challenging at this point. As each
running application has it's own PID, memory and threads, plus all the
associated communication credentials for X, migrating these processes to
more cpu's on more machines is not a trivial thing without disruption
that the client sees. LTSP5 does this at login time with the ldm server
load calculation. However, once connected, the client is firmly attached
to a single server. If it bogs down, all clients bog down.

The long term solution is a process used in high-end scientific
computing called single system image. The OpenSSI project is working
towards a solid solution in the lines of LTSP and OpenSource. There are
commercial projects like Mosix that already have this capability. This
process provides for a stack of servers that all provide cpu and RAM to
the cluster. A mother node monitors the load across all machines and can
migrate a process to a less used node as needed. As this process
migrates, all of it's associated records, ram and connections also
migrate seamlessly. The client never sees the change. This also allows
for hot node replacement as a node can be brought down, pulled, repaired
and replaced, and then restarted with no effect on clients other than
the loss of a bit of speed.

This has a ways to go before it is ready for use. It is under active
development and constant testing. Imagine the fun we can have when our
kids can reply to a normal students comment of "I use a Microsoft
windows machine every day at school." with "I use a 12 node, 96 cpu
super computer!"  :-)


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]