Date: Sat, 12 Apr 1997 15:12:05 -0700 From: "Jordan K. Hubbard" <jkh@time.cdrom.com> To: spork <spork@super-g.com> Cc: "Jeffrey J. Mountin" <sysop@mixcom.com>, Vincent Poy <vince@mail.MCESTATE.COM>, isp@freebsd.org Subject: Re: TS Holy War (was Re: Some advice needed.) Message-ID: <26230.860883125@time.cdrom.com> In-Reply-To: Your message of "Sat, 12 Apr 1997 16:15:13 EDT." <Pine.BSF.3.95.970412160403.2196C-100000@super-g.inch.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> As for servers, seperate everything from the get-go. Put mail on one > machine, shell on another, and web on another. I was around for a > migration from one machine to 12, and it wasn't pretty; in fact it was a > customer service nightmare.... Actually, I beg to differ on this point. I agree that buying good quality equipment is essential, but what I don't agree with is over-distributing yourself before the customer base merits it. I know of one ISP who had 3 machines doing the work of one (everything split out, as you say, but with only 200 customers) and it only increased the maintainance headache to *no* gain whatsoever. 3 machines to secure, 3 machines to maintain, it was evil. I stuck all the services back on ONE machine again and made a 2nd one a redundant spare for the 1st, with all of its important files rsync'd over nightly. The 3rd machine then came free to go to someone's house or something. :-) Now they have one machine which still spends most of its time twiddling its thumbs and a redundant backup which they never had before. If I'd been able to advise these folks in the beginning, I could have saved them money spend needlessly (for now) on the 3rd. Someday, if this ISP breaks the 500 customer barrier or so, I may start breaking things down again, though it will probably be just as easy to simply bump the primary machine's configuration up a notch, say to a Pentium Pro system or something. The secondary can remain as it is since it's only intended to be in service during short periods of outtage anyway. Sometimes it's just as easy to get yourself in a tangle from over-engineering the solution as well as under-engineering it (and over-engineering costs a lot more :-). Jordan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?26230.860883125>