Horizontal or Vertical Server Architecture?

zetes asks: "For a while now I have been a supporter of a horizontal server architecture/environment, where one server does one and only one thing and a business/department would then have numerous servers. This way if a service needs to go down (especially in a Windows Server environment), nothing else is affected. However, due to the rising importance of security in the last couple of years, I have decided that having fewer servers is both easier to manage and update and also provides fewer points of entry for hackers or virus writers. I am not going to a purely vertical architecture, where everything is on one server, but more of a hybrid (down from 10-12 servers to around 5). So what I am asking you all today is what you prefer to support or manage? One or the other, or a hybrid? And does the operating system or particular service(s) dictate this architecture to a certain extent?"

Comments

go with horizontal

[Anonymous Coward]

I prefer many servers with one major service each.

I have a group of about 10 FreeBSD servers and I use the "clusterit" port which has "dsh", distributed shell. There are also other packages with similar functionality, i.e., run stuff on many machines at once.

Each time I need to patch them, or do anything really, I just write a script like this (abbreviated):

#!/bin/sh
cvsup
cd /usr/src/sys/whatever
make clean && make depend install && make clean
kill `cat /var/run/whatever.pid` /usr/sbin/whatever

then I test it on my "test group"..

then I use "pcp" to copy it to each machine:

pcp script /tmp

then I run it

dsh /tmp/script

et voila, each machine is now up to date! Some minor testing and you're done. Anything else will be discovered by angry customers. :-)

I can admin many machines this way. I have several other homebrew scripts that do stuff like run and aggregate Tripwire output, check firewall logs, etc. Also similar stuff for the 2-3 Red Hat machines.

It's much nicer to have one service per machine because when one fails, just one service fails. when you have to move a service, you know exactly what the machine does, no "hidden forgotten services" like a funky FTP server on port 3573 or something.

it's just like refactoring your programming code .. break down your machines into easily understood groups and services.

my experience, anyway. grain of salt, $0.02, etc.

Depends on budget

[venom600]

In my ideal world, each server would have one, and only one, purpose. That way if a piece of software is compromised in such a way that remote access is granted, the damage is somewhat contained.

Also, from a maintenance perspective having single purpose machines make life a lot easier....especially if they are redundant single-purpose boxen.

But, sometime reality has to set in and some service consolidation may have to occur to keep hardware costs down.

Re:Depends on budget

[nocomment]

Yes but then you also have a lot more work to do via patching, and a ton more forensics work to do if a system is compromised. I like to cluster related services services together. I guess I'd be a considered a hybrid.

My firewall runs openbsd, pf, bind 9 (chrooted, primary dns) and snort (chrooted). Snort logs to a monitoring server that is running Mandrake 9.1, postgresql, apache 2, mrtg, some homegrown perl scripts, and nagios. The mail server is running all the mail services as well as dns (to speed up blackhole lookups). It all about clustering the services together that go well, and finding a balance that will allow for optimum network performance.