Tutorial

Hardware Specifications

The hardware specs for an LTSP server are well documented in the following article: ServerSizing

Specification of an LTSP server

The LTSP package makes use of a number of different services to boot LTSP clients, to download the LTSP client software to the terminal, etc. These services are supplied as part of most normal Linux distributions, but may not be enabled by default. The ltspadmin tool supplied with LTSP attempts to configure them and enable them if necessary.

In a simple single server setup, all these services are run on one server; this server also runs all the X clients (applications run by users). The size of server is then a function of the number of users, and the number and size of the X clients that users run concurrently. For this reason, there is no ‘one size fits all’ specification for an LTSP server; however, it is possible to list the factors which influence the size of the server required:

Factor	Smaller server	Larger server
Number of users	few users	many users
Number of different applications	users sharing small number of common applications	users all running different applications
Windowing system	light – e.g. XFce, qvwm	heavy – e.g. Gnome, KDE
Type of application	minimalist – e.g. Sylpheed, Abiword	full function – e.g. Evolution, OpenOffice.org, Mozilla
Bandwidth hogs	none	MPEG player, P2P networking...
Clients	run applications locally	low memory (swapfiles via NFS)

Experienced LTSP administrators have their own rules of thumb for estimating server size: for example, 256Mb memory minimum plus anything from 15-50Mb of RAM per concurrent user. Most implementations also quote ‘no more than 100 users per server’ as a sensible limit for a single server.

Scaling an LTSP server

LTSP server capacity can be increased in two dimensions:

• vertically – in a single server configuration, the specification of the server can be increased to support an increased workload. Increasing memory is often found to be a comparatively inexpensive way to deliver a noticeable performance improvement.
• horizontally – as the ‘LTSP service’ consists of a number of separate processes, it is quite feasible to run these on physically separate servers. This can be attractive if there is redundant equipment available which can reused as additional servers (typically PIII 600, 256Mb RAM or better). Sites adopting this strategy could also consider clustering techniques such as OpenMosix to provide automatic load balancing between servers.

There is no real alternative to analysing the performance of a running system, finding the performance bottleneck, and removing it (additional memory; faster disks; adding another CPU...). Even a simple ‘proof of concept’ set up using available equipment will yield valuable information. There is a wealth of material describing the tuning *nix servers – there is nothing special about an LTSP server.

---

Tutorial Home