Private Clouds and the RDBMS

July 22, 2009 · Posted in SQL Server 

Private clouds are all the rage right now. The concepts in the post applies to all virtualization products and all of the major enterprise databases servers so I am going to stay vendor neutral. My experience is mostly with VMWare and SQL Server so you may have to convert to the terminology of your platform.

So what is a “Private Cloud”? Right now, it is simply a large virtual machine cluster with management software. I expect it to mature to include more value added software like content deployment, dynamic load balancing of guests and other % as a service. It is often used during a tech refresh and\or a consolidation project. You can almost take two datacenter rows of 5 year old hardware and get it into two racks of current hardware chopped into virtual machines.

Let’s say our private cloud cluster consists of 5 servers having 4 sockets & 6 core with 96GB of RAM. Each virtual machine gets 2 cores and 2-8GB of RAM. This gives us about 60 virtual machines. Some platforms allow for oversubscription but we will keep it simple.

Here is a simple logical picture.

image

 

As you can see that if you can replace 60 physical servers and get as good or better performance then this is a no brainer. You save on power, space, CapEx hardware costs, licensing(depending on platform), and administration.

However, you also have 10 various Database Servers. They range from mission critical to dev\QA boxes. Where do these belong? It depends.

You will always get better performance out of bare iron because there is some overhead with virtualization. Some workloads suffer more than others. For example, a CPU bound workload will suffer the most and an IO bound workload will suffer the least(assuming you can give the VM enough memory.) Another consideration is the size of a VM. A database server with two cores and 2GB of memory will see less of an impact of virtualization than an 8 core VM with 16GB of RAM. Adding cores to VM’s does not scale linearly. Having said all of that, it make sense to leverage consolidation features of the database server and use bare iron for most private cloud applications.

There are still good applications for private cloud database VM’s. Here are a few:

  • Development and test environments
  • Supporting legacy environments that have old RDBMS installations
  • Support databases that require separation due to security or compliance
  • Sandbox environment to prevent resource intensive databases from impacting mission critical databases.

Here is the racks again with the database servers.

image

The ability to mix physical devices for virtual machines is one of the biggest benefits of a private cloud. Most public clouds do not offer this functionality. At least not yet. Use this design to get the most out of your environment.

Note: While I am recommending physical hardware for the DB server, they do run well virtualized sized up to 4 or 8 cores. However, since we would most likely need more power than that in this scenario, bare iron would be the best.

This content is published under the Attribution-Share Alike 3.0 Unported license.

Tags: , , , , ,

Comments

  • Great points, although I would say many shops have far more resources allocated to their DB environment than are really necessary. Also, with oversubscription as you mentioned briefly, some clients may be able to position virtual machine instances that have different peak times to further reduce idle computing resources. I've read (although never worked with it) that Mosso from Rackspace provides mixed availability of physical and virtual equipment. @giberti
  • The problem I have found, at least with databases on *nix and vmware, is the fact that you usually have to set memory reservations.
blog comments powered by Disqus