From owner-freebsd-isp Wed Jul 31 06:56:49 1996 Return-Path: owner-isp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA29963 for isp-outgoing; Wed, 31 Jul 1996 06:56:49 -0700 (PDT) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id GAA29958 for ; Wed, 31 Jul 1996 06:56:47 -0700 (PDT) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id IAA24111; Wed, 31 Jul 1996 08:55:42 -0500 From: Joe Greco Message-Id: <199607311355.IAA24111@brasil.moneng.mei.com> Subject: Re: number of servers To: sckhoo@asiapac.net (Khoo Swee Chuan) Date: Wed, 31 Jul 1996 08:55:41 -0500 (CDT) Cc: isp@freebsd.org In-Reply-To: <199607310648.OAA22857@gandalf.asiapac.net> from "Khoo Swee Chuan" at Jul 31, 96 02:58:43 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-isp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > hi, > > I am in a company which is chartered to startup isp > in my country. > I always hear people say about "keep it simple", > just one question, does that mean i should have one machine ( FreeBSD ) > each on mail/ftp/web/dns/etc etc or run multiple type of servers in > one machine, provided money is not a problem. :) > Which one is simpler? I'll want to have individual machine > doing specific job. WHat u think? > > Thanx. You may wish to study what I've implemented, it would be very applicable to a small-scale ISP and it should scale well in the future. Having one box per service gets a little hard to manage, and a little wasteful, when you consider that most core services (DNS, mail, etc) should be redundant. You will end up finding that reliability monitoring becomes more complex :-( On the other hand, having one box doing it all is a disaster waiting to happen. In general, I like to maintain the mindset that I should be able to lose any one machine and be able to rebuild it from scratch within a reasonably short period of time, should disaster strike. Backups are not a consideration, this is simply a rule to limit a machine's _complexity_. For example, my virtual Web and FTP server fulfills those two functions and nothing else. My services machines (currently Anacreon and Smyrno) provide DNS, mail spooling, and NTP time services. Although Anacreon provides primary DNS, these machines are otherwise very similar and act as redundant backups to each other. My routers route (and firewall) and provide no other services. The one machine that will tend to be more complex and nightmarish, no matter what you do, is a shell account server. Mainly thanks to all the s/w you have to load on it.. Anyways, it is a REALLY GOOD PRACTICE to devise and archive away a _standard_ template for _all_ your systems. There are things that I do to all of my FreeBSD systems, and I know what each one is and every time I install a new box, I run down the checklist. After that, it is good to have a sub-template for various types of machines, i.e. a Web server, etc. You should be able to recreate your baseline machines entirely from your templates. If you can't, you will lose your mind managing the complexity and the details. A simple, yet elegant (IMHO) architecture from the network point of view: --------------- --------------- --------------- --------------- |Border Router| |Border Router| |Border Router| |Border Router| | (To Peer) | | (To Peer) | | (To Cust's) | | (To Cust's) | --------------- --------------- --------------- --------------- | | | | |==========================================================================| | | --------------- --------------- --------------- --------------- | Core Router | | Core Router |-----| Virtual Web | | Office LAN | | (To POP's) | | (Internal) | | Server Box | | (PC's etc) | --------------- --------------- --------------- --------------- ___/ \ \ \_______________________/ / \ \ --------------- \ \ --------------- --------------- | News Server | \ \ | Terminal / | | Shell Acct | | | \ \ | PPP Server | | Server/Host | --------------- \ \ --------------- --------------- | \ | | | |=====================================| | | --------------- --------------- | | Services #1 | | Services #2 | \ | DNS/NTP/mail| | DNS/NTP/mail| \ --------------- --------------- \ | | |=====================================| There is a lot of room for flexibility here. Because the number of nodes on any particular network is kept relatively low, it is easier to do things like migrate the backbone to 100baseT (and due to the segregation of internal traffic, one has less concerns about an intruder on the shell box being able to see your administrative traffic and getting ahold of passwords on your other key systems). It's also relatively easy to add redundancy within the network architecture. Many ISP's make the Big Mistake of putting everything on a common wire - don't give into temptation. The network diagram above is, in fact, substantially similar to what I use, although it's been cleaned up a bit. There's obviously a lot to think about when deploying an ISP, and it needs to go much farther than just simple "one box or two" questions. ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/546-7968