Distributing Applications and Data

The topics that follow are intended to help you plan the overall configuration of the workgroup, in terms of what pieces of the workflow reside and run on what systems. This section will make better sense if you have already read “Choosing a File-Sharing Model”; you will notice that the discussion is biased towards the “Client-Server Model”.

Go to any of the following for more information:

HP-UX File-Sharing Model (V.4)

HP-UX introduced a new file-system layout at 10.0. The new layout is based on the AT&T SVR4 and OSF/1 file systems and is intended to provide benefits such as:

the separation of operating system software from application software
a foundation for file-sharing models such as “NFS Diskless Model” and “Client-Server Model”
consistency with other UNIX vendors

See the HP-UX 10.0 File System Layout White Paper on http://docs.hp.com for more information.

How Does this Help You Share Files?

The new layout is cleaner and more logical than 9.x, it is essential for NFS Diskless (see “NFS Diskless Model”), and it should make interoperating with other vendors’ UNIX systems simpler.

It doesn’t change the mechanics of configuring NFS mounts, but it does make managing them easier in one important respect: the segregation of non-“system” applications under /opt, and the changes applications such as Netscape have made to comply, mean that the server can now export a given application from a single subdirectory under /opt, rather than having to export several subdirectories for each application, or even the whole of /usr/local.

What To Distribute; What To Keep Local

Theory

The V.4 file-sharing paradigm divides HP-UX directories into two categories: private and shared (sometimes also referred to as dynamic and static).

Directories that contain a system’s configuration information are designated private and should not be shared via NFS.These are:

/ (root)
/etc
/dev
/var
/stand

The model also defines /home (for users’ home directories), /tmp and /mnt (for local mounts) as private, though in practice there is an argument for sharing /home and /var/mail (see “Should You Share Users’ Home and Mail Directories?”) In addition, /opt itself should not be shared, though its subdirectories are prime candidates for sharing.

Directories defined as sharable are:

/usr
/sbin
subdirectories of /opt

Practice

In practice, except under NFS Diskless (see “NFS Diskless Model”) it is not a good idea to share /sbin or directories under /usr other than /usr/local because it creates too much dependency (the NFS client cannot function unless the NFS server is up) and because it will cause problems when you try to upgrade the systems to a new HP-UX release. HP recommends you implement such tightly coupled configurations only under NFS Diskless (currently restricted to 10.x systems).

Directories you should consider sharing are:

application directories under /opt
directories that hold the data on which the shared applications operate
directories that hold projects on which a number of users are collaborating
directories that hold important, volatile data that must be backed up nightly

For example, the authors of this document keep the source text on a file server, a Series 800 system running HP-UX 10.20, which is backed up nightly. Our authoring tools and our web browser reside on an application server, a K-class server running 10.20, on which all software maintenance is done. Our local disks are not backed up and house no applications or tools that require outside support.

Distributing Applications

The main criteria here are performance and ease of management. The practical possibilities are:

store them on a server and distribute them to the workstations via NFS
store them on a server to which users log in to run them

The only configuration you should probably rule out from the beginning is to install each application individually on each workstation’s local disks; this might make sense for the occasional individual user with special needs, but software management considerations make it almost unthinkable as a general approach.

Given that you will store applications on a server or servers, is it better to run them on the workstations (via NFS) or on the server? Opinions are divided, and in practice you may well mix the two approaches. But bear in mind that modern applications are swap- and memory-intensive; it is often better to concentrate these resources on a server than to parcel them out to individual workstations.

For the greatest ease of management (backups and software maintenance) you should:

keep data in one central place where it can be easily backed up
maintain only one version and one copy of each application
if possible, concentrate applications on a single, powerful server

Aim for the simplest configuration that is consistent with acceptable performance.

Servers for Specific Purposes

The useful part of any computer system consists of applications and the data they manipulate. Your task is to decide how to deploy the workgroup’s applications and data so that they are adequately accessible, responsive, and secure.

This section assumes that:

you are going to put workstations (as opposed to display terminals only) on at least some users’ desks
the workgroup users will share at least some of the same applications.

You should plan to keep shared applications in a central location where you install, configure, back up and maintain them. Similarly, you should plan to keep all data that users share, and as much volatile data as possible (that is, data that changes frequently, whether or not it is shared by more than one user) in a central location where you can back it up easily, and from where it is distributed to the workstations via NFS.A system whose disks hold shared data is normally called a file server (even if the data actually resides in databases rather than ordinary files). A system on which shared applications are stored might be called an application server or a compute server; we’ll use application server.

In many workgroups, the file server and the application server are the same machine, which is simply a warehouse for everything that is shared and everything that needs to be backed up regularly. This may be convenient, and it may be the best you can do with the available hardware, but it is not ideal because the functions of a file server are different from those of an application server and may interfere with them: for example a CPU that is busy handling NFS requests will have fewer cycles for running applications.

File Server

Users normally do not log in to a file server; they get the data they need from it by means of NFS mounts.

The main requirements for a file server are:

plenty of disk space
Disk striping, which allows I/O to multiple spindles concurrently, may improve throughput.
plenty of RAM
fast I/O interfaces such as Fast-Wide SCSI.
proximity to the workstations it serves
Intervening hubs, routers, switches and busy LAN segments will slow things down.

This list is not meant to imply that CPU power is not important in a file server, only that it is not as important as it is in application server.

Application Server

If you have, or can afford to buy, the hardware resources, you should install applications on a system to which users can log in and run them. Whether they do or not will depend partly on how much power and capacity they have on their desktops, partly on LAN performance, partly on OS/application compatibility; but it’s likely that at least some users in the group will not be able to run all the applications they need locally, and others will prefer not to because, for one reason or another, local performance is poor. And of course some applications, such as large database applications, by their nature require capabilities not likely to be found on anyone’s desktop.

An application server, then requires:

All the characteristics of a file server, because in some cases it acts as a file server, distributing applications via NFS to clients that run them locally.
For performance reasons, this is probably not an ideal arrangement (the applications are likely to run faster if the server’s CPU is not busy handling NFS requests) but it’s a common one, and in practice it may work well.
In addition, a powerful processor, and possibly multiple processors, so that it can run large applications, and many applications concurrently.

For reasons of application compatibility, an application server may also need more frequent operating-system updates than a file server.