Over the next few weeks, I am working with a school to migrate their infrastructure from a standard Windows-based network to a Linux thin-client based network.
The existing network consists of around 90 desktops running Windows 2000 Professional and two Windows 2003 servers. The existing network had many of the standard issues plaguing most networks including viruses, malware, inconsistency of software versioning, licensing costs, and hardware failure.
The new network will be radically different. Instead of providing a standard desktop computer, all systems will be running from a cluster of high-performance servers.
The initial deployment involves 4 backend load-balanced back-end servers and 60 thin client stations (2 for each classroom and a computer lab of 35 terminals). Administrative and auxiliary systems will be migrated over the next year (including at least one additional back-end server).
The new network promises to deliver the following:
- No viruses/malware
- Centralized administration
- Minimal licensing cost issues
- Consistent software versioning
- Minimal hardware failure
- Minimal downtime
- Optimal use of resources
- Consistent, fast and responsive experience
No Viruses/Malware
No matter how Microsoft tries to spin the issue, virtually ALL viruses and malware are written specifically for Windows and other Microsoft software. Most of this malware focuses on the poor default security model of Windows or one of the many known security holes found in Microsoft software. Given the historical multi-user and security focus of Unix systems, these issues simply don’t exist providing a much more secure and trustworthy infrastructure.
Centralized Administration
The initial 60 thin clients (and eventually all 90+ thin clients) all share something in common – there is no local software to maintain! The existing network has a copy of Windows, Office, system tools and a wide variety of software loaded on each and every computer. Thin clients pull their software from the server. The server cluster operates in a fashion where updating software on the master node will propagate the change to the other servers in the cluster and thus, all the thin clients will benefit.
Needless to say, this will drastically reduce the cost associated with new software. Simply updating software on the master server will provide that software and version to ALL users on the network. No versioning issues, no per-computer software conflicts. Very simple, very easy.
Minimal licensing cost issues
As regular readers of this blog know, FOSS (Free, Open Source Software) provides two freedoms: free as in beer (cost) and free as in speech (ability to view and change the source code). For a school, costs are a major concern. Fortunately, FOSS delivers. With most of the software being FOSS, the cost of software is drastically reduced. As a result, it is possible to provide more software and capabilities for users and adjust the budget to provide additional workstations and hardware (printers, projectors, etc).
Consistent software versioning
As already touched upon, given the server-centric model, software only needs to be updated in one central location for everyone to access. Gone are the days of going to each computer and installing/configuring software (or attempting to build an MSI and utilizing group policies to deploy software (coupled with a script to adjust settings)). The system also provides the ability to keep multiple versions on the server so rolling forward and backwards is very simple. For example, I could load Firefox 1.0.7 in /usr/local/bin/firefox107 and the latest 1.5 in /usr/local/bin/firefox15 and simply symlink to the version I want people to use. If there is an issue, I can symlink to the older version and the next time a user launches the app, the older version would be used.
Compare this to deploying the same software to dozens of computers. This type of control is simply unavailable.
Minimal hardware failure
The thin clients are truly glorified 17� LCD monitors. They include a handful of ports (network, video, sound, USB) but ultimately do not have hard drives, memory, disk drives, CD drives or other items that tend to fail. As a result, the usable life of a thin client is much longer than a standard desktop computer (ie 10 years versus 5 years). Most of the “heavy lifting� hardware is located in the server room where the environment is controlled (humidity, temperature, power, dust) and the systems are rack mounted and stable (no kicking/moving of the computer). As a result, hardware longevity is expected (based on past experience) to be extended.
Minimal downtime
The network is built to be quite reliable. A thin client goes bad? No problem. Unplug the problem unit, plug in a new thin client. Thats it. No technical knowledge needed, no ghosting/hardware troubleshooting, no software reloads, etc. No spare thin client available? No problem. A user can pull their access card, plug it into another available thin client and continue to work where they left off..
On the server side, a node could go offline without impact to the network. This provides a lot of crucial redundancy. As a result, there is no critical single-point of failure. Peachy.
Optimal use of resources
One of my biggest gripes with traditional “fat client� computing is the wasted resources. Each fat client has only a fraction of the memory and the memory is loaded with much of the same information: Operating system, graphical interface, Internet browser, office suite, antivirus software, etc.
For example, the existing base software ends up using ~4GB of hard disk space and about 160MB of memory. This is the same for each computer (x60 computers). As a result, overall, this base software stack consumes 240GB of hard disk space and 9.6GB of memory. Ouch.
In addition to this, each time a user wants to use some software, it needs to be loaded from the (slow) hard drive into the (fast) memory. This results in slow load times.
In a “thin client� model, because everyone works off the same server, it is not necessary to load the same software multiple times. As a result, only 4GB of disk space is used for the applications (total) and only one copy needs to be loaded into memory. Evaluating this further, when one user is running a piece of software (ie office suite) it is already loaded into the fast system memory. When another user wants to use the office suite, it no longer needs to load from the hard drive and can simply access it from the fast system memory drastically reducing the load time. Seems much more resource friendly than loading the same software on dozens of computers.
Consistent, fast and responsive experience
With server resources being shared by all the thin clients on the network, we get some benefits. First and foremost, much more hardware can be thrown at the servers. On our network, we are utilizing fast 15,000 RPM hard drives, 4GB of dual channel memory, high-end multiple processors, etc. With much of the software being pre-loaded into memory when a user launches, it provides the benefit of extremely fast application load times as well.
Why is this important? Well for one thing, each and every user on the network gets to work as if they are using a high-end workstation computer. If down the road additional horse-power is needed, only the servers need to be updated for all users to benefit.
In addition, with this type of centralization, all users get the same experience. There are not multiple hardware configurations where certain users are stuck with yesterdays technology and decision makers (administrative users, IT staff) get the latest and greatest.
Conclusion
This is the start of something I think will be quite successful and perhaps a model for other schools to follow. As with previous projects, as this one is rolled out, I will be posting about the experience.. so stay tuned. 