[K12OSN] New K12LTSP installation

[Huck]

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 at 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!"  :-)