Article 12065 of comp.unix.admin: Newsgroups: comp.unix.admin Path: ornews.intel.com!ssd.intel.com!uunet!olivea!hal.com!decwrl!csus.edu!netcom.com!npm From: npm@netcom.com (Nancy P. Milligan) Subject: Re: How's this for an NFS layout? Message-ID: Organization: NETCOM On-line Communication Services (408 241-9760 guest) X-Newsreader: TIN [version 1.1 PL9] References: Date: Sat, 22 May 1993 23:26:30 GMT Lines: 364 Here's a synopsis of the replies I got. I deleted headers to preserve anonymity of the folks sending mail. The paper on "The Art of Automounting" is excellent. Definitely worth reading. This is a lot of information to digest, but some people have some great ideas! By the way, what I've decided to do is to use AMD, so that I'll be able to use it with the HP/UX's and any other Unix boxes that come along. I've adopted the idea, from "The Art of Automounting", of naming my partitions colorful names rather than numbered, dull names, because they will be more mnumonic. Besides, I'd rather mount partitions called "manatee", "walrus" and "squid" than "bp1", "bp2", and so on. Not that anyone but me will care in the long run. I don't quite see how having host aliases will help me out with AMD. It only examines the actual hostname, not the alias. But I found the AMD documentation to be very weighty and not entirely accessible to my brain at the moment :). Fortunately a kind person sent me his AMD maps and between those and the examples, I'm kind of catching on. It seems to be substantially different from, yet with many similarities, Sun's automounter. I know I'll have more questions to pose regarding AMD. The responses: ------------------------------------------------------------ >It sounds like you have thought about your NFS setup a great deal. >I recently got a good bit of info on a practical NFS setup strategy >from "The Art of Automounting" -- which covers exactly the issues >that you've got. It's available from anonymous ftp at >ftp.uwtc.washington.edu, I believe it's in the /Docs directory >(along with a lot of other good stuff!) and is called >TheArtofAutomounting.1-4.tar.Z (or something very close to that). ------------------------------------------------------------ >Your proposal sounds quite familiar. The principle that you are >(instinctively?) following is usually called "naming transparency". >Briefly stated, naming transparency means > > 1. Any file is accessible from all machines on the network, > by means of the same pathname, and > > 2. The physical location of that file is not specified as > part of the pathname. > >As you have observed, the benefits accrue to the users, to the CAD support >staff and to the system administrator. Users don't have to remember which >machine holds each data base, home directory, or software package. The >pathnames are shorter and easier to remember. The same pathnames are valid >on every machine in the local network. > >Naming transparency also makes life easier for the system administrators >and CAD support staff. By providing a simple, uniform environment, a whole >class of support problems has been eliminated. In addition, the automation >makes it easier to deal with unexpected changes. For example, a data base >may need to be moved because it outgrew the partition that was originally >allocated for it or because the disk drive or the machine must be taken out >of service. The move can be accomplished without causing users to change >either their scripts or their habits, because the pathname they use doesn't >change. Similarly, application packages can be moved from one filesystem >to another without causing all the users to change their paths. > >As you have described, the way to implement naming transparency is to >provide directories of symbolic links that point to the mount points or >to directories under the mount points of the large remote file systems. >Some people call a directory full of links a "linkfarm". > >However, since these directories contain the links to *all* the remote >file systems, I don't think you want to have everyone relying on one >machine to provide all the links. To maximize the reliability of the >scheme, you should think about having each machine maintain its own >replicas of the directories containing the links. The question then >becomes, "how do you collect the pathnames, build the directories >containing the links, and distribute the replicas?" > >That is a very good question, because existing tools only solve part of >the problem. For example, rdist can simplify distribution of directories >containing links but it doesn't solve the problem of collecting the >information and creating the links. The NFS automounter also places the >burden of collecting pathnames and maintaining tables onto the system >administrator. > >Before I go further, let be describe the history of our experiments in >this area. We have a Domain ring with about 90 Apollos and a collection >of about 70 Sun and HP machines on a few Ethernet segments, all connected >together. We use NFS primarily on the Ethernet side, and Domain services >on the Apollo side. Problems with Domain/NFS have prevented us from doing >large-scale sharing of file-systems between the Apollo machines and the >machines on the Ethernet, but the scheme for providing naming transparency >is the same in both environments. At our site, the IC designers are free >to create, rename, or delete CAD data bases on some disk partitions at any >time, so we need an automatic way to maintain transparent pathnames on all >these machines. > >We haven't tried the technique you describe of setting up hostname aliases >for the major servers. We do try to standardize the names of the filesystems >that are exported from each machine, however, and mount them in a standard >place on all the other machines. For example, several machines might have >a /db partition (real generic name), and they would all be mounted (by >the automounter) under /net on all the other machines: > > pangloss:/db is mounted as /net/pangloss/db > parsifal:/db is mounted as /net/parsifal/db > kundry:/db is mounted as /net/kundry/db > >Actually, each /net/ point is a link maintained by the automounter, >pointing to /tmp_mnt/net/. This is pretty much default behavior >for the automouter; we don't try to make it do any really fancy things... > >The earliest and most unreliable method we used was maintaining directories >of links manually on each machine. The disadvantages of this approach are >obvious: it requires someone (guess who) to change the links on all the >machines whenever applications or data bases were installed or moved. >Invariably, over time each machine acquired a slightly different set of links. > >For a while, we used scripts to maintain link farms on a central machine, >and all the other machines on the network contained links to or mounts of >the central link farms. We were able to automate the collection of >pathnames so that the central link farm was kept up to date, but the >system was not reliable because everyone depended on one machine. > >To mitigate the effects of the central machine going down, we began to >maintain replicas of the link farms on other machines. A script, scheduled >by cron on another machine, watched the central machine and copied the >links to the replicas whenever they changed, and would redirect all the >machines to one of the replicas if the machine holding the master copy >went off line. > >We realized that the most reliable system would be for each machine to >maintain its own link farms, so that downtime on any one machine would >have no effect on the others. The barrier to implementing this scheme >was the inefficiency of the scripts. > >We have a program now that maintains the link farms on each machine. >It runs as a cron-scheduled task, several times a day. It collects the >names of the various home directories, data bases, and CAD tool installations >under the NFS-mounted file systems, and changes the links automatically >if a uniquely-named directory is moved from one filesystem to another. > >It also keeps a little (text) data base of the directories that it is >supposed to watch, their modification times, and their contents. If any >of the remote directories are changed, the program re-reads them to >determine if it needs to add or change any links in the link farm that >it maintains on the local disk. By caching the timestamps in a local file, >it can avoid collecting information from all the remote file systems every >time it performs an update, which would generate a lot of unnecessary >network traffic. > >If you are interested, I think I can provide you with the source. (I'll >need to check with my boss, first). It's general enough that you could >use it as is, simple enough that you could modify it easily, and small >enough that you could rewrite it fairly quickly (if you can't stand my >coding style, or something). > ------------------------------------------------------------ You are on the right track. Adding an intermediate layer of indirection is a powerful administrative tool that few administrators seem to catch on to. I will suggest a few refinements, though, which I have learned from the experience of implementing exactly what you describe. I like to collect related things together in one place, which greatly simplifies administration and keeping things straight in my own mind. It also tends to make the entire system self-documenting. Remember that manageability is directly proportional to understandability. I mount all of my local disks under /export (whether or not they will actually be exported). On tortuga, I would mount the bp1 partition on /export/bp1 instead of /bp1. Likewise, I do all NFS mounts under /import. On tortuga, /import/bp1 would be a symbolic link to /export/bp1; on other machines, /import/bp1 would be a mountpoint. Finally, I would collect all of the pathnames that users use under one directory. For example, I'm in the EE department, so I put all non-vendor files under /ee. Using your organization, I would have /ee/user, /ee/appl and /ee/projects. Now, one NFS mount gets the whole show. This also helps the users understand your system--you can tell them that everything we own is under /ee (substituting whatever name makes sense for your site). One word of warning. Your users will find the real mountpoints and use them. You can minimize this by proselytizing, but you can't eliminate it altogether. My other suggestion is that I strongly recommend that you consider using the amd automounter. It is more robust than Sun's automounter in dealing with down servers and other problems. Its map syntax has a rather steep learning curve at the beginning, but you get a lot of power out of the deal. Although I started out with /import populated as I described above, I am now to the point where /import contains only one directory: /import/amd. Now I can move disks around with abandon and I never have to make any changes on the local filesystems (such as changing a symbolic link to a real directory so that it can become a mountpoint). It's all done in the amd maps. I will use one of your directories as an example. I would have an amd map named "amd.project". This map would be distributed via NIS, and the automounter on every host would mount the map on /import/amd/project. One of the entries in the map would look like this: # This is for the folks on the 3rd floor who think # money grows on trees. I had to move it to tortuga # because our money grows on rose bushes. overbudget host==tortuga;type:=link;fs:=/export/bp3/overbudget \ || type:=nfs;rhost:=tortuga;rfs:=/export/bp3/overbudget Note that it is simple to document your activities, something you cannot do with symbolic links (well, you could use readme files, but those tend to get scattered all over the place; with automounter maps everything is in few easily-located files). You will probably get at least a few responses from people telling you how inefficient your extra layer of symlinks is. Ignore them. Doing work for us is what we buy computers for, isn't it? ------------------------------------------------------------ In article you write: >At any rate, what do you folks think of automounter these days. Can >I depend upon it working well? Does it get badly messed up when a >machine crashes with active mounts? unfortunately, yes. It has that annoying habit that comes with being single-threaded; i.e. one good server hang and poof. It does recover pretty well in my experience, but... I still use it though, rather than suffer through the effort of switching to AMD. It's one of those things where you have to balance the problems vs the effort. Do you forsee your servers going down a lot? We try not to. Other than that, we haven't had much in the way of problems with it. Of course, for us, automount is one of those legacy things we brought along with us; we switched to automounter when it first came out, and before the existence of AMD, so we already had some inertia going. ------------------------------------------------------- In comp.unix.admin you write: >I'm going to be running HP/UX and Sun OS 4.1.3, and NFS. I don't >even know if HP/UX has an automounter. It does, but it's worse that Sun's. >At any rate, what do you folks think of automounter these days. Can >I depend upon it working well? Does it get badly messed up when a >machine crashes with active mounts? I use it all the time on 52 Suns, 29 NeXTs, and 2 HPs. However, I don't use Sun's, NeXT's, or HP's automounters. Sun's is the best of a bad bunch. I use the AMD (Auto-Mount Daemon) program that you can find at any good archive site near you. It compiles as-is on Sun & NeXT, with minor changes on HP. It doesn't hang, it's more configurable, it's remotely controllable with the amq program, it's excellent. Here's an amq example (eos is my files server, mama is my workstation): : raphael@mama; amq -h eos / root "root" eos:(pid176) /usr/spool/MHSnet direct amd.usr /usr/spool/MHSnet /usr/lib/news direct amd.usr /usr/lib/news /usr/spool/news direct amd.usr /usr/spool/news /usr/lib/newsbin direct amd.usr /usr/lib/newsbin /usr/man direct amd.usr /usr/man /home toplvl amd.home /home /u toplvl /etc/passwd /u /m toplvl amd.mentor /m /home/kwanon ufs /dev/sd4c /export/kwanon ============================================================================== npm@netcom.com (Nancy P. Milligan): > Under SunOS 4.1.1 I had some problems, can't quite recall what they were, > with automounter. They may have resulted from my own muckings about, I > didn't investigate that far before I gave it up. Pretty soon I'm going > to be vastly increasing the number of nodes, users and externals disks > and automounter would be really handy to manage the NFS mounts. > > I'm going to be running HP/UX and Sun OS 4.1.3, and NFS. I don't > even know if HP/UX has an automounter. > > At any rate, what do you folks think of automounter these days. Can > I depend upon it working well? Does it get badly messed up when a > machine crashes with active mounts? > -- > Nancy P. Milligan npm@netcom.com > or > npm@dale.cts.com We (uofa cs dept) have been running the 4.1.1 automounter with no problems on all of our machines. It minimizes startup time, and reduces drastically the number of active mounts on any machine that exports disks (since all servers are accessable to all clients here). Only problem is when a server crashes. References to that servers disks from a client that does *NOT* currently have then mounted will block references to other unmounted server disks from that client till the crashed system comes back up. The reason is automount is single threaded, and it blocks doing a mount of the down system. Outside of that, no problems to report. ============================================================================== In article you write: >Under SunOS 4.1.1 I had some problems, can't quite recall what they were, >with automounter. They may have resulted from my own muckings about, I >didn't investigate that far before I gave it up. Pretty soon I'm going >to be vastly increasing the number of nodes, users and externals disks >and automounter would be really handy to manage the NFS mounts. > >I'm going to be running HP/UX and Sun OS 4.1.3, and NFS. I don't >even know if HP/UX has an automounter. > >At any rate, what do you folks think of automounter these days. Can >I depend upon it working well? Does it get badly messed up when a >machine crashes with active mounts? The 4.1.3 automounter had a lot of fixes rolled into it; I thought it was pretty stable. (There was a jumbo patch for the 4.1.1 automounter that smoothed a lot of the rough edges, too.) On the whole I think an automounter is a Big Win, and I don't think you'll have trouble with the 4.1.3 automounter. ============================================================================== One thing which we do here is to assign servers their own alias for widely mounted filesystems. If a host goes down (or we just decide to spread/ combine drives), then all we have to do is change around the aliases). Example entries include: 137.82.8.33 fs3.cs.ubc.ca fs3 thumper grads1 grads2 grads3 cslocal grads4 grads5 project4 137.82.18.180 gummo.cs.ubc.ca gummo imagerred imagerwhite imagerblack imagerpuce 137.82.18.48 chong.cs.ubc.ca chong imagercyan imagervertigo Thus we would mount grads1:/usr/grads /nfs/grads1/grads1, imagerwhite:/usr/white /nfs/imagerwhite/white etc. (we use much the same symlink indirection that you do). If Gummo went down, however, all I would have to do is move imagerred and imagerblack to (say) chong while black and puce go to fs1. After changing the YP maps, I wouldn't have to change anything locally on our many machines, I'd just need to login, unmount them and remount the filesystems. When gummo came back up, then the process would be reversable. ============================================================ what you have in mind is very similar to what i finally did in my lab. i have several data partitions attached to various machines. originally, i actually (and stupidly) called them data1 data2, etc. this forced me to have unique automounter files for each machine. YUCK! i hated this and finally decided to do something about it so i renamed the partitions to dd1, dd2 for mounting on the various host machines (fstab entries) and then used automounter to mount. For example, machine:/dd1 on /data1 for everyone. it's wonderful! i also cleaned up the home partitions from /home/machine to machine:/users on /home/machine. there are other things that have i've fixed such as having a global /usr/local. anyway, i have the same automounter files on all machines and life is much easier. i am using sun's automounter and have had no problems, but i am careful to keep a very simple and straightforward setup. i've heard very good things about amd and would love to have the time to look into that since it has source. one of these days perhaps. i'm also lucky in that i'm only dealing with suns so far. i have the feeling that if non-suns start appearing i would be grateful for an automounter with source code. -- Nancy P. Milligan npm@netcom.com or npm@dale.cts.com