Eric wrote:
> SQL Architecture Opinion
>
> Hello. I am looking for your opinions on an architecture solution that
> our System Architect came up with for our SQL Servers within our IT
> division. Essentially, his idea is to implement one large SQL Server
> that all databases will run off of, regardless of use. Here is some
> base information about our setup:
>
> We have approximately 20 SQL Server. A small number are for our public
> website applications. They are in a separate zone and do not contain
> any protected/private data. There are approximately 200 databases of
> varying size (most under 1 GB) with varying uses and importance. We
> also have 4 major 3rd party applications with a database backend. When
> deploying a new application, I determine which server to put it on based
> on uptime requirements and load. I understand that 20 servers is
> excessive, but my request is the following:
>
> What do you guys think of having a single fault tolerant SQL Server for
> ALL databases, combining public/private data, high load needs/low
> priority, essentially putting all of our eggs in one basket. I already
> have my opinion, but I want to extend the opportunity for people in the
> industry to comment on this particular idea. Thanks in advance!
>
> Eric

More machines = more administration and more maintenance. It also means
more licenses. However with a single server you get a single point of
failure. Without a failover cluster such setup is generally not a good
idea.

This being said, there is another scenario: grid computing. If you
currently have 20 machines, you could build a load-balancing cluster
with your 20 servers and run VMWare on top of it. Then you could make
as many virtual servers as you need. With this setup, all your virtual
servers would benefit from the cluster reliability and make the best
use of the CPUs. The processing power of this grid would be much more
impressive than any big server you could afford.

Regards,
lucm