[K12OSN] Tossing around an idea...need some input

[David Trask]

"Support list for opensource software in schools." <k12osn at redhat.com> on
Saturday, August 13, 2005 at 10:16 AM +0000 wrote:
>David Trask wrote:
>
>>Ok...first the layout....
>>
>>I have 2 K12LTSP servers....both are single NIC servers since all
>machines
>>are on the same subnet....no private subnets for terminals...everyone on
>>the same network.   To simplify this I have a seperate machine that runs
>>DHCP.  DCHP is turned OFF on the K12LTSP boxes.  I use the "next server"
>>and "option root path" on the DHCP server to tell the terminals where to
>>go to get their image (kernel).  Now...up until now I've only had one big
>>K12LTSP server so all of this was easy...now I have another and would
>like
>>to try a combination of load-balancing and/or failover.
>>
>>snip --->
>>  
>>
>
>>Ideas.....thoughts?  Suggestions?  Perhaps a script or two?
>>  
>>
>I have been scratching my head over this subject too.
>
>My first thought was round robin DNS. Round robin DNS works great for 
>http, ftp and even mail servers but a quick response from #LTSP informed 
>me that there is no name resolution at the early stages of the LTSP 
>client boot sequence.
>
>I was wondering if the logic could be built into the os on the terminal?
>
>For instance if you drop to a shell in SCREEN_02
>
>and unplug the network cable you see "nfs at 192.168.0.254 not responding"
>
>at this point we have lost control of the os because / is nfs mounted 
>but there is a 1MB /tmp mounted on a ram disk and is still there.
>
>seems like it would be possible pass an argument that says if IP X is 
>not responding try IP Y


I think you're on to something here.  Obviously if the message "nfs at
192.168.0.254 not responding" is being produced, then something is
obviously "in the know" and thus can tell us there's a problem...so
therefore the mechanics to "harness" that answer would be necessary. 
Something along the lines that....if 192.168.0.254 is not responding via
nfs....then try 192.168.1.254...for example.  The trick would be figuring
out how to do this.  Then the other stuff you mentioned below to rerun
pivot_root etc. (more below) I'm cross posting this in the hope that some
of the LTSP guru's will see this  :-)
>
>
>Since we have multiple ltsp servers running and / is mounted off of 
>server1 whats stopping us from mounting all available
>root dirs as:
>
>/
>/ server2
>/ server3
>/server4
>
>and so on.
>
>if server 1 goes down rerun the pivot_root (refer to step 9 in the 
>theory of operation)
>
>
>The above is for fail over.
>
>
>For load ballancing
>
>at step 7 and 8 in the theory of operation we have already loaded the 
>kernel and dhclient runs.
>Quote:
>"A small DHCP client called* dhclient* will then be run, to make another 
>query from the DHCP server. We need to do this separate user-space 
>query, because we need more information than the bootrom retrieved with 
>the first dhcp query."
>
>For multiple ltsp servers it seems like we need even more information. 
>Like what's the state of all our servers. Run a script that queries 
>servers and builds a file. Apply logic to said file and determine what 
>server dhclient will poll.
>
>Am I barking up the wrong tree here?
>
>John

One last thing....think about how cool this is.  A few years ago we were
all simply wondering how to get ONE Ltsp server up and running....now
we're in a situation where many of us want to know how to provide
load-balancing and failover.....shows how far we've come doesn't it?
>
>
>
>
>
>
>
>_______________________________________________
>K12OSN mailing list
>K12OSN at redhat.com
>https://www.redhat.com/mailman/listinfo/k12osn
>For more info see <http://www.k12os.org>



David N. Trask
Technology Teacher/Coordinator
Vassalboro Community School
dtrask at vcsvikings.org
(207)923-3100