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

personally

[larry bagina]

I prefer a doggy-style server architecture.

It really depends

[Halvard]

Really it does. If you are after increased security, server consolidation isn't necessarily the way to go in any environment. For example, placing additonal daemons on a single machine adds rather than reduces the number of potential exploitable holes a single system has. Running Exchange and MS SQL or MySQL and Sendmail or whatever on the same box presents a greater number of potential points of vulnerability that a minimalistic install and just Exchange or Sendmail or whatever simply because more things are running on the machine. This same concept can be used to distribute updates from your distribution vendor (if that is the route you take) from a single source which has the added benefit of reducing your bandwidth consumption.

Also, reducing the number of servers doesn't necessary reduce the the amount of administration. Most admins download and patch servers one at a time regardless of the environment. You could for example (in a *nix environment), have a base environment server that you used to do all of your patching work/distribution on/from; then you create the package of your choice (RPM, .deb whatever) for install on the other machines using an update script. Or you could copy the binaries, conf files, etc., over to the other machines instead of packaging. For a Windows machine, you can script the patching as well using a decent login processor like KiXtart with a login script that checks recursively for patches and applies what you want. Or you could use Perl and command line tools to accomplish this across your servers (workstations too). This is beyond most Windows adminstrators. It shouldn't be but it is. I've been administering Windows and networks since just after NT 3.1 Advanced Server shipped, Netware about the same length of time, and Linux servers and networks about 5 or 6 years and most Windows admins are too indimidated or lazy to learn anything other than the GUI that ships. I've done this done on all environments for years and years and have seen or know others that do this too.