Path: utzoo!mnetor!uunet!husc6!tut.cis.ohio-state.edu!triceratops.cis.ohio-state.edu!karl From: karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) Newsgroups: comp.sys.pyramid Subject: Re: Advice Wanted on File Servers for a Diskless Network Message-ID: <11219@tut.cis.ohio-state.edu> Date: 21 Apr 88 15:05:56 GMT References: <13504@comp.vuw.ac.nz> Sender: news@tut.cis.ohio-state.edu Lines: 125 In-reply-to: duncan@comp.vuw.ac.nz's message of 15 Apr 88 05:34:44 GMT duncan@comp.vuw.ac.nz writes: Our department will shortly be buying a small number of (20 or so) diskless workstations for staff and graduate student use. The options currently appear to be [Sun3/[56]0's or HP 9000/300's]. The two problems are deciding on the appropriate file servers, and figuring out which workstation(s) to buy. Personally, I would recommend the Suns. We're using both here, and my clear preference is for the Suns. The HPs have enough differences in them that they cause quite a bit of grief in convincing them to cope with the heavily BSD-and-NFS environment in which we work. The HPs are considerably more SysVish than BSDish, with the result that a lot of things on them are incompatible at some level with our BSD systems, notably including our Pyramid 98x, on which reside major things like the department-wide /usr/spool/mail filesystem. Consider the problems of a SysV mailer, believing in setgid-mail delivery, as opposed to a BSD mailer, using setuid-root delivery. We found a solution to this, so that the HPs can mount Tut:/usr/spool/mail like everybody else, but let's just say that comedy is not pretty. There is, of course, the 14-char filesystem. Also, HPs do funny things with a single filesystem which is shared among the server and clients, with personalizations for each workstation being accomplished with something HP calls a `CDF,' a Context-Dependent File; a CDF is actually a directory which contains filenames which are the workstation names, and in turn those files contain the contents of the intended filename. If you look at /etc/passwd, it looks different on each system, but if you cd /etc/passwd+ (the `+' is how you talk about a CDF in its directory form), you can see machine-name filenames. It's weird stuff, and if you're mostly a BSD shop as we are, these sorts of things can be quite a problem. The local Sun agents have suggested that for 20 or so workstations we might be looking at two Sun 3/180's to handle the load. That's close, but they might be trying to sell you too much hardware. We have 11 Sun3/180's; we put 12-20 clients apiece on them. You'll find that ND won't serve more than 20 clients (it's a hard limit), so if you're going to >20 workstations, >1 3/180 is an absolute necessity. Performance is quite acceptable if you have sufficient disc controllers. That is, one of our 3/180's is currently serving two Super Eagles off of a single Xylogics 450 (or is it a 451? can't remember now) controller. This is also the server with 20 clients - paging activity can cause real problems. We're anxiously awaiting the re-installation of the 2nd controller there. On any system with 1 controller per disc, things are really fine and acceptable. The problem is in paging activity. Buy workstations with LOTS of memory, to cut down your paging traffic. HP's suggestion was similar but based on HP 9000 model 350's. I can't say much about load on those systems, other than to say that we have 1 server with 6 clients, and it has certain perf. problems. It is not clear at this time if it is due to hardware infant mortality or software problems. We know that we are getting some long packets on our backbone ethernet (1524 bytes), and that in turn is causing us trouble with our Proteon gateway boxes that connects our dept with the rest of the OSU campus network. Another option is that as part of the same equipment proposal we hope to upgrade our current pyramid 90x (8Mb main memory - no data cache) to a pyramid 9805 or 9810 with probably 16Mb memory). The pyramid's main task would be to support 30-50 undergraduate and graduate student's (not simultaneously). Would it also be able to support the load of acting as a file server for the above number of diskless workstations doing typical (whatever that is) work? The Pyramid can handle it after upgrade. I wouldn't try it before upgrading, though, especially without the cache. Our 98x has 32Mb and serves 30-50 people simultaneously during the heavier part of the work day. It's currently mid-morning, and we are already getting substantially loaded; by 2pm or so, there'll be 45 people logged in. [111] [9:19am] tut:/dino0/karl> uptime 9:19am up 2 days, 23 hrs, 30 users, load average: 4.11, 3.40, 3.05 [112] [9:19am] tut:/dino0/karl> He's got a fair amount of disc on him, 6 Eagles, which would be 7 if the 7th were working. /dev/iop/pdisk00a 19102 16042 1148 93% / /dev/iop/pdisk02a 19262 170 17164 1% /tmp /dev/iop/pdisk00c 47950 40946 2208 95% /usr /dev/iop/pdisk10a 19318 8882 8504 51% /usr/spool /dev/iop/pdisk00g 290054 256612 4436 98% /u0 /dev/iop/pdisk01h 387318 332188 16398 95% /u1 /dev/iop/pdisk10f 338822 285804 19134 94% /u2 /dev/iop/pdisk11f 338558 310332 28226 92% /u3 /dev/iop/pdisk03i 367646 29154 338492 8% /usr/spool/news /dev/iop/pdisk03a 19262 4068 15194 21% /usr/lib/news /dev/iop/pdisk02b 29054 18 26130 0% /ai0/sys /dev/iop/pdisk02f 338558 260712 43990 86% /ai0 Tut also mounts 14 filesystems from assorted Sun servers and other Pyramids (we also have 2 98xe's and 2 90x's). Most of those filesystems are exported to 140 Suns, about half of which are inhabited by grad students, faculty, and staff, and the remaining half by undergrads using filesystems resident on systems other than Tut. Tut slows down in mid-afternoon when his direct timeshare load hits 50 users and the workstation load is similarly high, but he keeps working and things keep getting accomplished. He's configured with about 110Mb of swap space (3 Eagle `b' partitions and one `a'). Regarding the choice of workstation. I believe it is possible for Sun workstations to boot over NFS now, rather than using the old "nd" protocol. Would this be possible with a Pyramid acting as a file server, or would we need at least one Sun file server? Pyramid demo'd discless Sun service at the Dallas UniForum in February. It's not ready for release, apparently (they were using a hacked SunOS 3.2, from what I was told), but it's Almost There. Can the HP workstations running HP/UX also boot over NFS? Would they be able to boot from a non-HP file server? How well could we expect a mixed environment of diskless Sun's and HP's (and possibly PS/2's) to work? Sorry, don't know, such ideas don't fit in with our plans/goals. Hope this helps, --Karl