 |
» |
|
|
|
If you are about to set up a new workgroup, or make large
changes to an existing one, you must first decide how you will distribute
the computing resources among the users. The biggest of these decisions
concerns how users will share files and applications. Will they: The answer is probably some combination of the above, and
could possibly be all of the above. The sections that follow are
intended to help you explore each model and choose a predominant
one. Multiuser
Model | |
A multiuser system
is a system to which a number of users log in to do their work,
using a terminal directly connected to the system, or a terminal
emulator on a remote system connected by a modem or LAN. AdvantagesMay be the best use of the computing
resources of a large system. See “Distributing Applications” Simplest model:. Only one system
to configure, back up and maintain. No operating-system co-existence issues. Simplest possible hardware/OS/application matrix.
Security: Easy to protect
physically (e.g, in a locked computer room). Allows you to keep sensitive data (or all data)
off the desktop.
DisadvantagesLarge system required, possibly with
multiple processors: Special power and climate requirements.
Fragile: If system crashes, or is down for
maintenance, no one works. Failure of any component likely to affect everyone.
Inflexible:. Can’t easily redistribute
load in response to changing (or miscalculated) use and performance.
SummaryThis model may be the right one for you if you have, or can
afford to buy, a high-powered system, and your users are all using
the same applications to manipulate data that can be stored centrally,
not parcelled out onto local disks. If this is the case, your users
do not have to forgo the advantages of windowing: XTerminals provide
the same display capabilities as workstation monitors. Even if this model is not suitable in its pure form, you may
well want to use it in combination with a more distributed approach;
for example, you may want at least some of your users to have workstations
on their desks, but still allow them (or require them) to log in
to a high-powered “application server” to run applications
that need the memory, MIPS, disk space or other resources of a big
system; or you might deploy your applications across two or three
high-end workstations and have users log in to those to run them. NFS
Diskless Model | |
The term NFS
Diskless describes systems that use special features
of NFS to share the root file system. (Diskless means
that the clients do not require a disk; in
practice, many “diskless” workstations have at least one
disk). In this document, we use the term to refer specifically to
the HP implementation of NFS Diskless. | | | |  | CAUTION: NFS Diskless is a good choice for workgroups, or
portions of workgroups, running 10.0 through 10.20, but it is not
supported on later releases. | | | | |
AdvantagesEasy and efficient
sharing of resources: Single-point administration (via SAM). Physical security: Easy to keep valuable peripherals,
and disks containing sensitive data, in one central place and lock
them up.
DisadvantagesNot supported after HP-UX 10.20. Fragile: If the server crashes, or is down
for maintenance, no one works.
Heavily dependent on LAN and subnet performance: Swap to local disk recommended for
best performance.
SummaryIf you will be solely or mainly responsible for administering
the workgroup, and you do not need to run HP-UX 11.0, you should
consider NFS Diskless. This model has become less popular as the price of disk space
has declined, but is still the simplest way to administer a group
of workstations. SAM, the menu-driven System
Administration Manager, has been tailored as of HP-UX
10.01 to make it easy to administer an NFS Diskless cluster from
a single console. See Chapter 10 “Setting Up and Administering an
HP-UX NFS Diskless Cluster ” for more information. Client-Server
Model | |
Client-server is
an umbrella term we are using to refer to workgroups that share
resources other than the root file system; that is, the workstations
run HP-UX from their own local disks, but depend on an NFS server
for non-“system” files and applications, and may also
have common arrangements for printing, backups and user-access. AdvantagesFlexibility: Can easily redistribute resources
in response to changing needs and conditions and the results of
trial-and-error.
Robustness: Failure of one system or component
will not necessarily affect everyone. Data and other resources can often be switched quickly
from a failed system to a working one, minimizing downtime.
Performance: By assigning roles such as file
server, application server and client,
you should be able to deploy your hardware and software resources
for the best possible performance.
Shared responsibility: Depending on your users, you may be
able to turn over to them most of the work of administering their
own workstations, reducing your workload in the long run.
DisadvantagesComplexity: Matrix of operating-system versions,
application versions and peripherals may be unwieldy. The more widely distributed the data, the harder
it is to back up NFS mounts can create complex cross-dependencies
between systems; these can become hard to keep track of and pose problems
during boot and shutdown.
Performance: Heavily dependent on LAN and subnet
performance. Running applications locally may alleviate LAN bottlenecks,
but at the cost of losing the computing power of a large server.
Disorganization: If users are even partially free to
administer their own systems, complexity, and unexpected problems,
may increase beyond your power to manage them.
SummaryBecause of its flexibility, and perhaps also because it seems
to many people a natural way to arrange things, this model is increasingly popular,
and this document devotes much of its space to it. In theory, this model allows you to have the best of all worlds;
everyone in the workgroup can use the best combination of the group’s
resources - compute power, mass storage, printing, display capabilities
- without being so dependent that they all have to go home if a
server goes down. In practice, there are difficult trade-offs. If you want everyone
to send and receive their mail locally, for example (rather than
depend on a mail hub) you will have to configure and maintain mail
alias files on each workstation, a lot of work in a large organization.
If you want to reduce LAN traffic by having people run applications
and store data locally, you will not only have to arrange to back
up that data, but may also find yourself buying disks and memory
to get acceptable local performance. On the other hand, consolidating resources on servers should
save you time and money, but it leads you back toward a mainframe-like dependency
on a few systems, with an additional dependency on the performance
and reliability of the LAN. If you adopt this model, you should allow some time (and if
possible, some of your budget) for trial and error and refinement. “Distributing Applications
and Data” some guidelines and
suggestions. |
Printable version
