Please check the status of this specification in Launchpad before editing it. If it is Approved, contact the Assignee or another knowledgeable person before making changes.
Packages affected: unknown
We will make it easy for a system administrator to configure multiple Edubuntu servers to share the tftp/NFS load for TCs. This will provide a modest performance enhancement and service redundancy.
Note: The original proposal in this spec (session load balancing) has been superseded by https://wiki.ubuntu.com/LDMLoadbalancingSupport .
If multiple Edubuntu servers are available it would be best if there is no single point of failure for booting thin clients.
Freida is the system administrator for a school with 500 TCs, and she has three Edubuntu servers configured with https://wiki.ubuntu.com/LDMLoadbalancingSupport. She configures the three Edubuntu servers to let each client select a TFTP/NFS server, so that when one server goes down its TCs can immediately reboot with one of the remaining servers and user downtime is minimal.
Romulus is a system administrator using 2 Edubuntu Feisty+n servers with 50 TCs, and he is making extensive use of local apps. At the beginning of each workday, ~45 employees typically boot their TCs and start OpenOffice, GIMP, and Blender within a short window of time, and the load on NFS is significant and causes delays. Romulus configures his two servers to divide the TC NFS root mounts evenly between them, in order to avoid the bottleneck.
This spec is about TFTP/NFS being shared among multiple servers to provide failover in the case of a server crash, and load balancing for the bright future of Edubuntu with local application support. This spec is not concerned with login sessions being directed to one server or another (for see https://wiki.ubuntu.com/LDMLoadbalancingSupport). This spec has nothing to do with migration of any sessions or processes from one Edubuntu server to another.
TFTP and NFS root are handed to the TCs by DHCP, so the solution will fundamentally involve DHCP. It would be good to automate configuration of this feature as much as possible.
DHCP failover seems to be the best plan, but this can use more discussion.
Data preservation and migration