|
|
The Net Impact of Thin Clients
The term "thin client"
generally refers to user devices whose functionality is minimized,
either to reduce the cost of ownership per desktop or to provide more
user flexibility and mobility. Thin can denote a range of
capability—that is, anything less than a full-fledged PC running a
complete operating system, running local applications, and operating on
locally stored data.
Various types of thin clients have
existed in the past; X-terminals and diskless workstations are the most
familiar examples. Recently, the term has been reinvigorated by relating
it to several new Internet-oriented devices: the network appliance, the
network computer, and the networked PC (which is really a standard PC
that can also act as a thin client for some applications).
For any thin client, reducing the client
role results in an increase in the server role in delivering complete
applications. In a traditional fat client/server deployment (Figure 1),
the client PC generally stores files and applications locally, enabling
independent operation. The server is used to store completed files,
making them available for sharing with other users, or to provide
network services such as printing, faxing, and e-mail.
Figure 1. Traditional Fat
Client/Server Deployment
Thin Client Models
There are two general models of thin client function. In the extreme
case (Model 1 in Figure 2), the thin client device is simply an engine
for user input and presentation. The server receives keystrokes and
mouse commands generated by the client and provides screen display
updates. The server provides all application, data storage, and
communications functions. This model is sometimes referred to as
server-based computing. It is the model used by Citrix and allows
incremental migration to a complete thin client architecture through the
use of a gateway server. The server looks like a fat client to
traditional application servers, but provides a thin client extension
over the enterprise network to user desktops.
In a slightly less extreme case (Model 2
in Figure 2), the server sends bits and pieces of data and applications
to the client. The client operates on that information independently,
provides client-based presentation and I/O, and requests more data or
application functionality as needed. This distributed model is enabled
by the Java programming language as well as other languages. Various
forms of this model are becoming popular for dynamic interactions
between Web sites and remote users.
Figure 2. Thin Client Models
By using thin client models, IT managers
are trying to reduce operational costs. The Gartner Group has estimated
the total cost of ownership (TCO) of a PC-based internetwork at almost
$12,000 per year per desktop. Of this, only a small portion (about
$2,500) is related to capital equipment costs (including software).
Roughly $4,000 per year per desktop is spent on administration and
technical support, and approximately $5,500 per year is spent by end
users on nonproductive time associated with troubleshooting,
customizing, or tinkering with their PCs and application software. The
thin client architecture centralizes the control of the software, which
simplifies version and configuration management, accelerates software
upgrades and rollbacks, reduces the number of trouble reports, and makes
trouble resolution more efficient.
Deployment Considerations
Two questions must be considered before deploying thin clients in any
form:
- Are the server and
data storage subsystems ready to support thin clients? Generally,
server and data storage subsystems take on a greater role when thin
clients are deployed. All aspects of the server farm should be
examined to ensure readiness for thin client support. N-tiered
application architectures, bigger servers, clustered/load-balanced
servers, internal storage area network (SAN) bandwidth, and
SAN-to-backbone throughput should all be evaluated to ensure the
capacity of the system on the server side.
- Will the network
support thin clients? In a thin client environment, network
availability is paramount. If the network is down, users can't work
on files, presentations, or reports, or even make local data entries
for later synchronization. To ensure 24x7 network/application
operation, end-to-end systems redundancy should be deployed along
with instrumentation and applications to support rapid
troubleshooting and automatic failover.
Because fewer operations are performed
locally at the client, the use of thin clients results in a greater
sensitivity to network latency. By implementing RMON-2 probes with
related monitoring applications, the network manager can gain a detailed
knowledge of application-related traffic flows between clients and
servers, identify bottlenecks, and predict future trends. A variety of
measures can then be considered to ensure that thin client application
performance meets user expectations. These measures include:
- Deploying switching to the
desktop
- Upgrading backbones to
Layer 3 switched networks
- Increasing and managing
bandwidth (especially WAN bandwidth) via techniques such as 802.1p
traffic prioritization, application-aware switches, DiffServ, IP and
ATM Quality of Service (QoS), and policy-based networking
The information contained in this
document represents the current view of 3Com Corporation on the issues
discussed as of the date of publication. Because 3Com must respond to
changing market conditions, this paper should not be interpreted to be a
commitment on the part of 3Com, and 3Com cannot guarantee the accuracy
of any information presented after the date of publication. This
document is for informational purposes only; 3Com makes no warranties,
express or implied, in this document.
Copyright © 1999 3Com Corporation. All
rights reserved.
Get
this document in PDF form
|
