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.
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.
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".