1

We're moving to a Hyper-V cluster with data center licensing soon, and will be able to spin up several virtual servers if needed. We have about eight applications which use SQL databases. Is there any advantage/disadvantage to setting up a separate SQL server for each application, versus keeping everything running on one large SQL server?

5
  • Thank you mfinni. I ask because at the moment we have one physical SQL server. Once the cluster is in place, I have a choice whether to place all the apps on a single powerful virtual SQL server or several smaller virtual servers, or some compromise. It seems advantageous to me to give every app its own server; that way if app "A" needs maintenance, app "B" is unaffected. However, I'd like to know of any potential downside to this plan, for example the added burden of administering the extra servers, in case anyone
    – Cory
    Jan 11, 2013 at 15:17
  • ...has tried out either or both scenarios and has some pros/cons in mind.
    – Cory
    Jan 11, 2013 at 15:18
  • Edited my answer.
    – mfinni
    Jan 11, 2013 at 15:28
  • Thank you again mfinni -- it makes sense that unless I was to pick up some kind of advantage by separating the apps out to different servers, the added overhead is just wasteful of resources. I appreciate your analysis.
    – Cory
    Jan 11, 2013 at 15:34
  • Once you've allowed some time to see if other answers come up, don't forget to mark an accepted answer.
    – mfinni
    Jan 11, 2013 at 15:41

1 Answer 1

0

The fact that this is on HyperV is mostly a red herring in this situation. Approach it with the same criteria you would use for placing different SQL databases on same or different instances on actual hardware.

  1. System performance limits - memory, IO, CPU, threading/processes, etc. If putting the DBs all together will swamp your performance, scale out onto more instances on different hardware (or with a VM, scale up your provisioned hardware if possible.)

  2. Other criteria, like backup windows, scheduled jobs, clustering, which is generally an extension of the above. Security isn't generally a concern, unless you have different databases that need to get authentication from different untrusted domains.

Per your comment : if you're doing it with all on one instance now and not having problems, keep doing that, on a correctly-sized VM. Adding more VMs will just use more resources for additional OS instances. What sort of maintenance would you be doing on one database that is impacting other databases? Unless you're doing something like re-indexing in one database that is impacting performance in other systems, and they don't have overlapping maintenance windows or periods of allowed reduced performance. This is what I was getting at by saying the only real reason to do this is for performance reasons. Otherwise, try to consolidate.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .