| |
|
|
As more systems are placed under the administrator's responsibility, the effort required to maintain project software and data increases dramatically. If file-system layouts are allowed to evolve independently, the problem compounds. As the number of machines moves beyond 100, a central plan is essential to keep the administration team's sanity intact.
In a traditional workstation-server setting with each cluster of workstations using the same server, consistency between servers can be maintained without much difficulty. But many UNIX environments cannot be planned so meticulously. Unlike traditional PCs, a UNIX desktop workstation is powerful enough to be a small-scale server. It is not unusual for a workstation to be placed on the desk of the person in charge of a project and have all files associated with that project stored locally on that workstation. When others need to access the files over the network, the desktop workstation acts as a server. This flexibility is a benefit of UNIX, but maintaining a large number of such systems can be an administrator's nightmare. Two techniques can tame the file-system jungle: an automounter and a plan. Automounters provide easy access to needed file systems. The plan is a documented method for laying out file systems on all machines and for providing sensible automount access points. Used in concert, these two techniques can make file-system management more workable. The details of configuring an automounter are beyond the scope of this article. What automount provides is the ability to define multiple mount points under a particular directory. The mounts are established only when needed, and the file system is unmounted when no longer in use. An automounter also provides a level of indirection and centralized control. It lets the administrator create virtual pathnames and arbitrarily point them at concrete directories. The directory's actual location on the network will not affect the pathname, providing the administrator the ability to move the data as needed. This abstraction also could be achieved with symbolic links, but such a scheme would not provide mount-on-demand capability.
Composing A Plan
A file-system layout plan should
Two types of pathnames need to be defined by the plan. The first type is the global or public name. This is the name by which all users refer to a directory tree. If you use an automounter, this would be the automount pathname. The second type is the local or private name. This pathname has significance only on the machine where the files reside. Thus, if the automounter were configured to mount /apps/local from server:/files/local, /apps/local would be the global name and /files/local would be the local name. Partitions can be classified as either system or local. Examples of system partitions are /, /usr, /var, /opt, and /tmp. Local partitions do not have such commonly recognized names, but historically, systems have used names such as /mnt, /user, /home, and /homes. System partitions are those that are established at installation time and have significant meaning to the system and the suite of standard applications. When you install extra programs and packages, they sometimes end up on a nonsystem or local partition. Home directories almost always end up in a local partition. The plan should define a naming scheme for all local partitions. Administrators often face a common dilemma when installing new software applications: whether to place them in a standard location such as /usr/bin or in a special location such as /usr/local/bin. I believe locally installed software should remain separate from system software. This means designating a special location for such applications. However, some packages leave you no choice: they force you to install items in system partitions.
An Example Plan
I will describe a layout plan that has worked well for me. Do not take this as the ultimate way to do file-system layout, but as a concrete example on which to build. Create a top-level directory called /files to contain all user partitions. Create a directory in /files for each local partition. Number them starting with 0. You will end up with names such as /files/0, /files/1, /files/2, and so forth. These will be the local mount points for the partitions. Classify your data by type. Every installation has at least two types: home directories and applications. If you have projects that need to share data, use a third classification with a name like proj or project. Expect to find data of each type in multiple locations. Create an automounted file system for each type: /home, /apps, /proj. Create a directory in each user partition (/files/0, /files/1, and so forth) for each data type that resides in the partition. Now you might have pathnames such as /files/0/home, /files/0/proj, or /files/1/apps. In each of these directories, create subdirectories to contain the specific homes or applications required. Now you can create a mount point in your automount map for each subdirectory. Figure 1 provides an example map for /home, and Figure 2 shows one for /apps. These examples are indirect maps for Sun's automounter, but they should give you a good idea how this plan would be implemented with any automounter. I prefer to place large software packages, such as EMACS and FrameMaker, in separate directory structures. The alternative is to crowd /usr/local with everything under the sun. Not only is /usr/local difficult to integrate into a distributed and automounted scheme, it also can grow large and disorganized if it contains too many big packages. Several packages (such as PBMplus and mh) make heavy use of the UNIX tool-building philosophy. Install several of these in /usr/local/bin, and soon everyone will give up on performing an ls in the directory. If you split packages into separate locations, users can pick and choose what they want to clutter their paths with. If users don't want the 100 or so executables from PBMplus on their path, they can leave that name off without losing access to other packages. Finally, by placing everything in the same location, you will quickly run out of disk space. Then you must resort to symbolic links to glue everything together. Down that path lies madness. Some benefits
to this approach may not be apparent at first. It works as well
on multiple-disk servers as it does on single-disk workstations.
It is easy for an administrator to find all applications installed
on a given host (
A Word About Applications
The plan also should include a standard layout for applications. It is best to follow the traditional UNIX directory-naming scheme: bin for binaries, man for manual pages, lib for libraries, etc for configuration files, src for sources, and so on. These directories can be created in the application's top directory (/apps/emacs/bin, /apps/emacs/lib, and so forth). Not all applications lend themselves to this structure, but it is best to stick to the structure wherever possible. When installing applications in an environment like this, it is best to create the directory and add it to the automount table before beginning the installation. Then the installation process can use the global pathname safely to refer to the top of the application's tree. If the installation process asks for an installation location, you should not give it the local pathname. Some installation scripts use the pathname in the scripts and configuration files they install. Also, the local name does not work across your network.
Summary
Using the automounter as an integral part of this plan has advantages. An application can be replicated to allow balancing of the NFS load and can provide redundancy. A new version of an application can be installed (even on a different machine), and switching over to it is as easy as changing the automount map. Users should be using the global pathname, which will not change. Home directories can be moved to provide better control over balancing disk utilization. A consistent naming scheme will reduce the administrator's workload by providing uniformity across the entire installation. Users also will appreciate the layout because it is easier to find files. If you already have a file-system nightmare, it is not too late. Compose your plan, then figure out a transition path. The transition will be painful and disruptive, but the end result will be worth the effort.
William LeFebvre has been banging on UNIX systems for 15 years
and has been studying Internet technology for almost as long. He
currently operates Group Sys Consulting and can be reached at wnl@groupsys.com.
Figure
1
Figure
2
This article first appeared in the August 1997 issue of UNIX Review.
|
||||||||||||||||||||||||
|
Home | Top
|
|||||||||||||||||||||||||
