Embedded Terminal Server HOWTO

Copyright © 2002 by Tom Lisjac.
E-Mail: vlx at users.sourceforge.net


Goals - Why do this?

A Terminal Server Architecture offers a number of advantages over the deployment of self standing PC's.  In addition to centralized server and application maintenance, recycling older hardware that might otherwise be discarded is very cost effective. Reliability also improves because the only moving parts in the diskless workstations are the cooling fans.

While salvaged machines usually make great diskless workstations, using older equipment for the server isn't without risks.  If a workstation fails, only one user is affected... but if the server goes down, all the workstations go with it. Even with new, fast and highly reliable hardware, the "single point of failure" mode is a concern in mission critical enterprise applications where workstation downtime must be held to a minimum.

The purpose of this document is to present an integrated architecture and package of documentation that can be used to enhance existing LTSP environments and will ultimately support the creation of an easy to install, CD bootable distribution.

Technical Overview

Figure 1 shows an LTSP system in a typical institutional or enterprise environment. Workstation requests are made to a stand alone server via eth1 and access to the internet and local network is via eth0. This configuration also includes a separate network interface to an optional openMosix array via eth2.

Figure 1. LTSP Single Server Configuration

Figure 1.

With older equipment or "mission critical" applications, the server represents a significant single point of failure. The aggregation procedure described in this document provides a method of adding a secondary server to this configuration as illustrated in Figure 2.

Figure 2. Embedded Terminal Server Architecture

Figure 2.

Creating the ETS configuration shown in Figure 2 involves making an identical copy of a working LTSP system (with openMosix, Samba, OpenOffice and other options fully installed) and configuring the primary and a cloned secondary to act as peering DHCP servers. The latest version of ISC's DHCP package (3.0.1 rc9 as of this writing) supports both DHCP fail-over and load balancing. Mandrake 9.0, Red Hat 8.0 and Debian 3.0 ship with this version.

In this scheme, the original LTSP server becomes the "Primary" and an additional machine (preferably identical hardware) will become the "Secondary". Of course, it would be possible to manually install and configure two separate systems... but it isn't recommended. Doing two separate installs makes it difficult to insure functional interchangably of the servers. A missing service, utility, mapped printer or Samba share on one of the servers can cause intermittant production problems that will aggrevate users and be difficult to troubleshoot. The server hardware doesn't have to be identical... but the system image running on each box definitely should be.

While using DHCP as the load balancing agent has the advantage of simplicity, the technique is currently limited to 2 servers. Increasing the number of clustered servers is possible using other techniques such as Linux-HA, but these approaches would significantly increase the complexity of configuration.

The primary server should be in it's final configuration state before starting the build of the secondary. This means that it's permanent IP addresses have all been assigned, all of it's services have been fully configured and it's overall functionality has been thoroughly tested.. You might also want to consider and address a few security issues before you begin.  When we configure the cluster, all we're going to do on the primary is turn on DHCP load balancing... everything else should "just work".

Contents  Next
This Project is generously hosted by SourceForge.net Logo