Date: Thu, 11 Mar 1999 23:18:04 -0500 From: "Gary Palmer" <gpalmer@FreeBSD.ORG> To: Mark Mayo <mark@vmunix.com> Cc: freebsd-isp@FreeBSD.ORG Subject: Re: Mail server setup Message-ID: <89008.921212284@gjp.erols.com> In-Reply-To: Your message of "Thu, 11 Mar 1999 19:44:22 EST." <19990311194422.A4381@vmunix.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Mark Mayo wrote in message ID <19990311194422.A4381@vmunix.com>: > NFS gets you one thing that locally attached disk can't - multiple > front-end hosts can see the same set of data. For setups with several > hosts handling the mail, it is trivial to build a SMTP/POP proxy to > route people to the correct mail server based on username (I know, I've > done it..). That gets you nice horizontal scaling to infinity pretty > much, but doesn't help you out in terms of availability or serviceability. > How do you do an OS upgrade on a front end host with no cx impact? What > happens if a host goes down? What happens if your disk array goes tits up? However you do it, you end up with the same problem. Whereever the mail is stored becomes a SPOF (Single Point Of Failure), unless you go to some sort of HA scenario, and none of the HA products that I've seen are any where close to being `mature' enough for my liking. In my case, we have large Sun boxes as message stores, accessed by multiple front-end boxes which do data indirection to present one `virtual' message store to the public. Sure, you can do weird stuff (delivering to two different hosts in parallel), but thats really expensive (tm). We have other tricks up our sleeves which we'll test soon for message replication :) > I'm not saying I like NFS.. but when done correctly (use a real RDBMS for > most of the POP stuff to eliminate trips to the NFS server for mail checks, > avoid locking over NFS, failover NFS servers listed for clients, etc.) > you can build a decent NFS based solution that scales and is very tolerant > to host / filer crashes. I'd do it with local disk if I could, but I haven't > been able to come up with a solution based on local disk that I'm satisfied w > ith.. Because of software reasons or hardware reasons? To be perfectly honest, to my mind, the lack performance in NFS writes it off to my mind instantly. I can get high performance out of a host based backend with a fraction of the work of what you propose in the above paragraph. > At any rate, building large email solutions is a neat challenge, and I'm not > sure NFS or local disk has clear advantages. In the past, I've leaned towards > local disk, but now I'm swinging over to the NFS camp.. 8) Traitor!!! Hang him at sunrise!! :) > Of course, that probably has just as much to do with my hatred of Sun's > ludicrously priced A5000 disk arrays I'm using right now as it does with > anything else.. ;) That and the fact that I'm happy as pie with my NetApp > F760 test units, and F740 production filers.. Anyone who buys storage direct from Sun needs their head looked at. The A3500 is a rebadged unit from Symbios (now LSI Logic), which we get for a lot less than Sun charge for it. The A5000 is JBOD on fiberchannel. No write cache. Interesting unit. Sucks for real applications. Again, LSI have a real fiberchannel based RAID system, and are trying their hardest to make it interoperate with other equipment enough (e.g. FC switches) that it may actually work, unlike Suns stuff. > Interesting how Sun started making such statements shortly after they > started pushing SIMS - which doesn't run over NFS reliably. Coincidence? :-) SIMS is close to the right architecture IMHO. Its just way too expensive and large-scale to replace NFS /var/mail in a lot of instances. But thats another story. If you go to the lengths you describe above, and have the RDBMS database, yada yada yada, then yes, NFS may actually scale and perform. However, thats a lot of work, which I don't feel is justified when the proxied-to-large-backend solution works just as well. Gary -- Gary Palmer FreeBSD Core Team Member FreeBSD: Turning PC's into workstations. See http://www.FreeBSD.ORG/ for info To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?89008.921212284>