roughly :Server groups or single server and database groups

  • Hey folks, I know this topic might sound rough , but I though this could open up a great discussion about whether to use several servers to keep your database groups on and manage the whole server group or to have a single server(Strong enough) to keep all your database groups in one place .

    In my case our company has over 30 databases which can be divided into 5 - 6 database groups (By nature) . I wanna know what are the Pros and Cons of each method (in the eye of a DBA) .Plus for HA/DR considerations which one is more handy, economic, easy to manage ?

    Cheers ! 🙂

  • Love this quote:

    Scale Up

    - Servers are like pets

    - You name them, and when they get sick, you nurse them back to health

    Scale Out

    - Servers are like cattle

    - You number them, and when they get sick, you shoot them

    *Bill Baker, Distinguished Engineer, Microsoft

    Scale out is certainly easier to troubleshoot.

    When everything is on one box you run into the possibility of one problem database affecting the whole server.

  • That's a lovely quote , sums up everything

    No doubt T-shooting is much more easier when separated , but this also means much more headache for the DBA to manage them all ,plus i think the synergistic attribute makes a lot of sense economically.

    you might need 5 cores of CPU for each server to be up and running but get them together 8 cores can do the job.

  • If you find too hard to administer 5 servers of 6 databases each v 30 databases on one server, you'd not the DBA for me. There isn't much overhead to moving across servers here from the DBA side. I'd discount this entirely, or train your staff, or get rid of your staff and find people to train.

    In terms of code, if there are dependencies between databases, then certainly across server is more complex.

    However. At some point you might need more resources, so you will separate your databases. In this case, having code that can move makes sense.

    Now, I wouldn't completely separate the databases without reason. There is a cost in efficiency for use of resources on more machines. There is cost. If you can use fewer machines, then there is less to pay for, support, replace parts, etc. However fewer machines is greater risk of interruption if something breaks. That's your tradeoff.

    I prefer to scale out to at least 2, and maybe more, machines. I can use more memory at a lower cost, typically, across machines to support databases. If I need more resources, another small(ish) box is cheaper than upgrading to a bigger box.

    However I have licensing costs. Those impact the decision.

    I'm not sure what you mean by groups in all of this. Is this some logical construct you have? Or do you have links between databases that put them in a group? If these are just for related data, and not linked in code, don't use group. It's misleading.

Viewing 4 posts - 1 through 3 (of 3 total)

You must be logged in to reply to this topic. Login to reply