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

[John Baillie]

David Trask wrote:

>"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?
>  
>
>>
>>    
>>

Yes Dave it is pretty cool, kind of a natural progression.

As to the root_pivot stuff

Prior to the root_pivot Linux is installed in ram drive.
As to your comment "something is in the know" I'd guess that something 
would be the kernel an it is running even though it's / is unavailable.

It seems possible that a lot of functionality could be put into a ram 
drive and made available to the kernel.

Quote:
This is where the fun really begins. During the kernel loading process, 
a ram disk image will also be loaded into memory. A kernel command line 
argument of* root=/dev/ram0* tells the kernel to mount the image as the 
root directory.
Normally, when the kernel is finished booting, it will launch the* init* 
program. But, in this case, we've instructed the kernel to load a small 
shell script instead. We do this by passing* init=/linuxrc* on the 
kernel command line.

There is lots of unused resources on a terminal in terms of processing 
power and RAM.

This is an important topic imho.

Martin Wolley posted a method the other day that was interesting but it 
requires a bit of record keeping.
The chooser is another method but the documentation is for older 
versions of k12 and in our environment I think it's better  to have it 
automated.
There are some who are saying overlapping DHCP is ok and others who say 
it's not ok.

In a mixed environment all on the same subnet I'm wondering what the 
effect of standalone PCs has on the IP addresses available to terminals. 
For instance PC1 reserves 192.168.1.1, iBook1 reserves 192.168.1.2 this 
may or may not be a factor but it appears that stand alone PCs could 
reserve all available ips for a particular terminal server.

John