Ubuntu Wiki

This basic spec have been implemented in gutsy. Next step is presented in LDMLoadbalancingSupport .

• Launchpad Entry: ldm-load-balancing

• Packages affected: ldm, ltsp-server

Summary

We will enable the capability to use multiple application servers. The goal is to spread the load by redirecting sessions on available servers.

Rationale

Currently, it is difficult to support more than a single log in server with LTSP. Supporting multiple servers will make it possible to scale to larger networks by adding additional servers and provide some server redundancy.

Use Cases

• Fritz is a system administrator for a very large scale network. He used to run windows terminal services that were always overloaded. Now he has to upgrade, and found out LTSP includes a load-balancing solution over multiple servers to share the load, and additionally provides basic fault tolerance. So he installs LTSP in this environment and the productivity of the customers increased significantly.
• Mike is the administrator of a cluster of terminal servers. To get the best experience for his users, he wants to take into account the capacity and load of servers to load balance sessions.
• Sandra is a university student. She starts a thin-client, and choses to start a session on a specific server that she knows has a special software installed.

Scope

• Offer a basic load distribution mechanism, that can be expanded with a more complete load balancing mechanism provided by external software.
• For now, assumes that servers are homogeneous and interchangeables, which means that they have the same supported languages and session types available.
• Doesn't support session resuming.
• The use of round robin DNS should not be recommended for load distribution, and may not be implemented.

Design

The role of choosing the server will be done by the thin-client, if there is more than one server in the known server list. It enables the possibility to let the user chose himself the server he wants to use. If the user doesn't select a server, then the session will be started on a random server in the known server list.

The client should be resilient to unavailable servers. If automatic mode is used, the terminal should try another server in the list. Unavailable servers shouldn't be selectable in the list of available servers. If no servers are available, then the user should be informed.

This design exclude the use of a network balancer like LVS, because it doesn't support the possibility to let the thin-client chose the server. Also, it needs a deep knowledge of networking, so it makes the solution complex. We want to avoid this complexity because the design should be simple and easy to use for the administrator.

Servers list may be ip addresses or DNS names. This assume that name resolution is working on the thin-client.

Implementation

There is an implementation of this concept here : LDMLoadbalancingSupport. This architecture has an algorithm of the second order, in which each clients pools every servers in a while. We should avoid pooling on a periodic basis to avoid unecessary load.

The variable LDM_SERVER will hold the servers names or addresses, each separated by spaces.

Automatic load distribution and balancing

Provide a script which pick a random server in the list of available servers. Allow administrators to use a custom script for more advanced load balancing. Include a hook in LDM to get a list of servers from this script.

Manual server selection

LDM should be modified to let the user select which server to log in to. When selecting a menu entry, a modal window opens. Available servers are listed in a table, with a rating. Unavailable servers are grayed. The user can chose in the list and click ok. The user can chose to select the automatic mode, then the server list is grayed completely.

Application server specific settings

Create an ldm-server package which includes ldminfod and other parts of ltsp-server only applicable to LDM sessions.

What about ssh hosts keys? There is a problem there, because each server's host key must be copied to the client root, and it's a bit more complicated since there are multiples servers.

The solution have been to copy each hosts key from every servers into one directory on the primary server, and they are managed by the update image script.

Outstanding Issues

BoF agenda and discussion

CategorySpec