SQL Server Private Cloud – Not for VMs Only (updated)

I was working with a partner architect last week on a ideas for a SQL Server architecture that would best fit a large customer that we are working with. We both were starting from the same place in our architecture discussion of private cloud with automated database provisioning massive server consolidation.

What was interesting is that we both called this “private cloud”, yet he was assuming no virtualization – just automate the provisioning based on application catogorization and consolidate under specific SQL Serverinstances. I had the same ideas, but ASSUMED virtualization.

The moral of this story, for me anyway, is not get caught into thinking too black box, that is, that to achieve many of the same benefits of a virtualized private cloud, that you must fully adopt virtualization. Now that being said, I prefer VMs as a consolidation practices generally speaking, because of the OS isolation and elastic scale.

But a key think to remember is that you can still take advantage of overall data center automation with private cloud on bare metal database instances, not just virtualized. I was sent a link to this Charles Joy demonstration of using the beta of System Center’s new Orchestrator (formerly Opalis) which is automating SQL Server. So certainly VMs are not mandatory for many of the private cloud benefits.

UPDATE: I just wanted to clarify what I mean above by “categorization”. When consolidating servers, to take best advantage of different hardware and networks and utilize the most expensive and fastest assets for the most appropriate purposes, you should classify databases & applications in accordance with their  business requirements as opposed to simply putting systems on machines that were pegged for that purpose. The classic taxonomy is silver, gold, platinum with different SLAs with RPO and RTO measurements. For example, 24 hour SLAs with 24 hours for resolution and 24 hours of data retrieval would probably fall into a silver category. While each level increases the responsiveness of the SLA, the corresponding RPO & RTO requirements mean that ultimately, you will end up with the most critical business systems residing on the most expensive and top-of-the-line equipment and staff. This is where part of the business value and ROI of server consolidation can be found whether you are creating a private cloud on bare metal or virtualized infrastructures.


SQL Server Maximum Availability: Denali & Private Cloud ?

As I am working my way through the latest updates in the betas of SQL Server Denali, I’ve been thinking about different architectures to maximize database and application availability with the new SQL Server platform. It is important to note that one the most hyped, popular and intriguing architectures for database and applications, both from my interactions with customers and Redmond, is utilizing what we call “Private Cloud”.

I’ve written about a SQL Server private cloud before in this blog and I often refer to it as “optimized data center” for customers. The reason for this is that for some, it can be confusing when software vendors are talking about public clouds like Azure, Amazon, RightScale, etc. or virutalized local environments in your data center. Private cloud is taking the concepts of Public Cloud like elastic scale, metered billing, self-provisioning, consolidated servers, maximum utilization of infrastructure to maximize, ROI, etc. and making those concepts viable in your own data centers.

SQL Server Denali introduces an update to database mirroring that combines the Microsoft technologies of mirroring, clustering and replication into a very simple easy-to-configure and maintain set of “availability groups”. With Denali, you can take databases that are part of an application, put them into this availability group and even have multiple replicas (aka database mirroring with multiple read-only partners) that you can report from or back-up from.

My thinking is that combining these 2 technologies will give the SQL Server DBA community 2 key things that were either not available before in SQL Server or are better now with this architecture:

  1. Combining applications into availability groups that allow me to move reporting and backups completely off the primary production database and to the replicas.
  2. Create a SQL Server farm where I can use the Microsoft System Center suite for server load balance, full server density, Live Migration for zero downtime patching and managing my instances as SQL Server virtual machines.

The slide below is from a presentation that you can download from the Microsoft SQL Server private cloud link that I included below. This architecture works with SQL Server Denali since I would configure availability groups for my application databases using AlwaysOn database replicas, which require Windows Cluster Server as shown below. The virtualization command and control software (Hyper-V and VMM in this case) will allow me generate a SQL Server farm where I can move the instances around from server to server, using Live Migration. So while HADR provides the tools for protection against failures and guest-level patching, Live Migration and VMM give me the ability to load balance, utilize full server resources and move running instances from server to server with no downtime. The assumption in this architecture, BTW, is that I am running a single SQL Server instance per VM, so that when I say “move an instance” in this grid architecture, I am moving a full guest OS VM.

Go here for more details on SQL Server Denali. And here is the Microsoft SQL Server private cloud home page.

Your thoughts and suggestions are very much welcome in the comments. Thanks! Mark

UPDATE: The SQLOS Team blog on SQLBlog added an excellent post that you should bookmark for SQL Server Private Cloud background info: http://sqlblog.com/blogs/sqlos_team/archive/2011/06/08/sql-server-virutlization-consolidation-and-private-cloud-resources.aspx