Redundant PXE/tftpboot servers separate from DHCP server

[Michael Redmond]

I need to find a way to implement redundant PXE/tftpboot servers on an 
existing net served by s separate DCHP server.

Details:

We run a centralized DHCP service that provides addresses for multiple 
VLANS. One of the VLANS is a protected net on which we can run 
less-secure protocols, like tftp. I have built a PXE/tftpboot server on 
that net to serve thin-clients operating in a "kiosk" mode (no 
dependency on server after boot - thin-client X application runs local 
to thin client). The boot server is separate from the DHCP services. 
This part works fine with the following configs (made a bit anonymous):

     host thin_serv.us.here.edu {
     	hardware ethernet 00:01:02:03:04:05;
	fixed-address thin_serv.us.here.edu;
	server-name "123.456.321.99";
	next-server 123.456.321.99;
	filename "pxelinux.0";
     }

(I am not sure if the next-server and filename entries are needed here.)

     host thin_term01.us.here.edu {
	hardware ethernet 00:01:02:03:04:25;
	fixed-address thin_term01.us.here.edu;
	server-name "thin_serv.us.here.edu";
	next-server thin_serv.us.here.edu;
	filename "pxelinux.0";
	option root-path "/opt/ltsp/i386";
     }

(I am not sure if the server_name is needed here)

Both the server and client are on the 321 VLAN

Problem:
I may end up building a network of 100 thin clients that need to boot 
from PXE/tftpboot server(s) that are separate from the fully redundant 
DHCP services that are provided. Having only one boot server is asking 
for trouble...it's a major single point of failure. So I need to have 
redundant boot servers for reliability. It would also be nice to have 
multiple boot servers for load management in case we end up with a 
classroom of thin clients that all might start up at the same time.

So the question is:
How to I configure DHCP entries to create a pool of PXE/tftpboot servers 
separate from the DHCP servers?

What I found so far:
1) Configure multiple boot servers on the restricted subnet and have 
some thin clients use one server, and others use other servers by 
setting "next-server" to the desired choice. This is easy by not robust, 
and it provides no load management.

2) Configure "multiple A records in the DNS for the TFTP server name". I 
don't have much control over DNS (another centralized service). And, 
because of TTL issues, this doesn't really solve the redundancy 
requirement. I am not sure this would provide load leveling unless the 
assignment through DNS had an attached script that selects the 
least-loaded, available server at the time a request is made (like 
"lbnamed"). We used to have lbnamed implemented here, so that might be a 
possibility, though not that appealing.

3) Use something tricky inside ISC DHCP (that I don't understand) like 
"option code 150" to create an array of IP addresses to use. The info on 
this is sketchy, but if I was able to:

(global)
option option-150 code 150 = array of ip-address;


     host thin_serv01.us.here.edu {
     	hardware ethernet 00:01:02:03:04:05;
	fixed-address thin_serv01.us.here.edu;
	server-name "123.456.321.95";
	next-server 123.456.321.95;
	filename "pxelinux.0";
     }
     host thin_serv02.us.here.edu {
     	hardware ethernet 00:01:02:03:04:06;
	fixed-address thin_serv02.us.here.edu;
	server-name "123.456.321.96";
	next-server 123.456.321.96;
	filename "pxelinux.0";
     }

     host thin_serv03.us.here.edu {
     	hardware ethernet 00:01:02:03:04:07;
	fixed-address thin_serv03.us.here.edu;
	server-name "123.456.321.97";
	next-server 123.456.321.97;
	filename "pxelinux.0";
     }

...

     host thin_term01.us.here.edu {
	hardware ethernet 00:01:02:03:04:25;
	fixed-address thin_term01.us.here.edu;
	option tftp-server-name "123.456.321.95";
	option option-150 123.456.321.95,123.456.321.96,123.456.321.97;
	filename "pxelinux.0";
	option root-path "/opt/ltsp/i386";
     }

(not sure if quotes needed around option option-150 args)

I have no idea if this will do anything useful, but it is the kind of 
thing I would like to do. And if it does something useful, I am not sure 
if code 150 is an actual implementation of failover and load leveling - 
but probably not.

---
 From discussion as far back as 2005 (with Eric Helm) on this list, the 
problem of PXE/tftpboot redundancy and load leveling seems to have been 
discussed, but I didn't see a clear example of resolution. Has anyone 
been successful, and if so, how?

Thanks
M Redmond