Thanks for the response. This setup is a little more complex and a lot more expensive than what we have. Since we only have 50 or so readers at the time, we'll go to a similar setup, on a smaller scale. Our reader machine is reading and writing to the Netapp and is fine. Our feeder machine is currently running innd 1.5.1 and has 4 4 Gig disks on it. Since it's a FreeBSD box we'll use ccd to stripe across the filesystem instead of using individual filesystems on each disk. I used to resist the idea, since it meant that if one disk fails, I lose my whole spool directory. I don't mind this as much now that we have a reader and feeder architecture. The next step will be to use Diablo as the feeder's server rather than innd. I guess we'll have to have the posting done on the reader machine instead of the feeder.
Dror
On Sat, 14 Jun 1997, Ragnar Lonn wrote:
We are running almost that configuration. We have an F540 used for spool and overview for the reader machines (multiple Ultra 170's that mount spool and overview read-only from the Netapp and run only nnrpd via inetd). Then we have one single Ultra that mounts the spool and overview read/write and is the only machine that can store articles. This machine accepts an incoming feed from our feed machine. The feed machine is another Ultra 170 dedicated to feeding - it runs Diablo and has a dedicated Voyager 3000 external RAID box (6x2GB) to store articles on.
On the reader hosts, nnrpd is started in slave mode with the "-S" flag, telling them to redirect all postings to the machine that has write access to the Netapp (the 'writer host').
I would think it's a good idea to not combine feeding and reading on the Netapp unless you have to. I think the two operations have fundamental differences that will lower performance compared to if you let the Netapp handle only reading and have a dedicated feeder machine instead that uses local disks to store transit articles.
In my opinion, a feed machine doesn't have to be as failsafe as a reader system either, so you can use local disks and RAID-0 on it. If the disksystem fails, you just have to have spare parts and someone that can replace the failed components fairly quickly and very little will have been lost. Of course, it depends on the circumstances - if you charge people money for feeding them, then maybe you have a stronger obligation to make sure the feed never goes down. But in most cases, a feed down is no disaster. When it comes up again, its peers will send it queued articles which it can then start relaying to its other peers and if the downtime is not too long, no articles will be lost.
Anyhow, I know of others that do combine feeding and reading on their Netapps and their systems apparently work well so maybe it just requires a little more tuning or maybe I'm just being paranoid (like they say, paranoia is reality on a finer scale :-)
Oh, and another thing. Following suggestions from Netapp people we have $NEWSLIB (history and overview, etc) on local disks on the Ultra that is the 'writer host'. Then we NFS-export $NEWSLIB on that machine to the reader hosts that mount it read-only. This gives the advantages of relieving the Netapp from having to serve clients with the very large history file as well as lots of small article files and it also makes management simple - any changes you do to config files on the writer host is reflected on the reader hosts immediately. No need to do multiple config updates to allow e.g. newsreaders from a new address. This idea also looks logical to me as anything that can simplify what a machine is doing, is good. Our F540 is *only* serving articles files and that is good to know - if we run into performance problems, finding out the cause is a lot easier than if the filer had been serving different kinds of files to different kinds of clients.
The disadvantage, of course, is that we rely heavily on the writer host. But I can live with that. A single machine rarely fails and it can be made fairly robust with mirrored disks, etc.
Our system seems to work pretty well now. We had some problems initially but they've been sorted out and the Netapp is running smoothly as well as the Ultras which are never very loaded (though, of course, we don't have all that many readers on them yet). Things look good so far.
Regards,
/Ragnar, Algonet/TNI
On Fri, 13 Jun 1997, Dror Matalon wrote:
We're using a similar configurations on a news reader machine. The feeder machine is still our old news machines with lots of disks. We'd like to migrate the feeder machine to the netapp too. I understand that at that point you put history and over.view on the netapp and start nnrpds from inetd instead of running innd.
I guess expire should be run on the feeder and so should overchan.
Anyone running this kind of configuration? Care to describe how it works and the performance you are getting?
On Thu, 12 Jun 1997 sthaug@nethelp.no wrote:
I would be very interested to hear from other people using NetApps for news spools for any advice on optimally configuring the NetApp for this purpose.
e.g., no snapshots, increase the number of inodes, no atime update, disable NFS over TCP, ...?
That last paragraph pretty much describes our situation - and it works like a charm! And yes, we have a private 100 Mbps Ethernet (crossover cable) between the Ultrasparc and the NetApp. We keep active, history and outgoing on local disk, and use the NetApp for articles and over- view.
The Ultrasparc/Solaris 2.5.1/NetApp system has been *extremely* stable for us. Not a single crash of any kind during several months of service. It just runs. We're happy :-)
Steinar Haug, Nethelp consulting, sthaug@nethelp.no
Dror Matalon Voice: 510 649-6110 DNAI -- Direct Network Access Fax: 510 649-7130 2039 Shattuck Avenue Modem: 510 649-6116 Berkeley, CA 94704 Email: dror@dnai.com
Dror Matalon Voice: 510 649-6110 DNAI -- Direct Network Access Fax: 510 649-7130 2039 Shattuck Avenue Modem: 510 649-6116 Berkeley, CA 94704 Email: dror@dnai.com