With the increase in resources limits in Hyper-V on Windows Server 8, I have been toying with the idea of putting every server on a Hyper-V instance.  Even if it is just a stand alone instance with one Hyper-V instance on a single physical server.

By having every server be a virtual server, I will have much greater flexibility in moving the server to new hardware for growth or disaster recovery reasons.  The virtual server would be like a little server package that I pick up and move anywhere.  I could then use virtualization replication to move to a new server with very little downtime or create a warm standby server.

I do recognize that the virtualization platform itself would add overhead and take resources away from the SQL Server.  However, I think the trade-off in increased manageability is worth it.  It won’t of course work for every database server, but for the most part my SQL Servers are modest in size and rarely need more than 128 GB of RAM.  I do spend a ridiculous amount of time moving between servers, so the time savings is worth it alone.

What are your thoughts?

When speaking about private clouds I find many people have a hard time trusting an infrastructure platform that they do not have control.   How do you know if you data is being backed up?  How do you know that your data is secure?  How can SLA be maintained if you don’t control the infrastructure?  And that is not even addressing the auditor’s concerns.  The fact of the matter is that many companies will never move to the cloud, the risk to their business continuity is not something that they are willing to risk to a third party.

The reported cost savings are not something that can be ignored, but I am still skeptical on the real savings of the cloud.  Microsoft recently announced they are cutting their Azure SQL Storage prices almost in half, but you still have to pay for computing time, data access and bandwidth.  In my experience with hosted databases, customers have no idea how much resources they actually use.  While the idea that you pay for only what you use sounds appealing, it is until you have to pay more than you budgeted.

I expect that in the next few years we will see more companies getting comfortable with the cloud slowly, they may move non critical systems to a cloud provider, but keep mission critical data in house on their own private clouds.  The cloud providers are already looking for methods to make it easier for business to transfer to the cloud. Having a private cloud in house will give you flexibility, security and control to decide for yourself on upon which cloud your data lives and hopefully one day to move between clouds easily.

Now this is a topic that annoys me.  Everyone on the planet is acting like this a new idea. However, At the PASS summit in 2008, I presented a session on “How to Build a Private SQL Server Cloud” and have been running my own private SQL Server cloud since the launch of SQL Server 2008.  I thought now is the time to do a series of blog posts on what I am doing with Private Clouds, this is the first in that series.

Back in 2008, the cloud was just beginning to buzz and I thought wow this is a great idea, but I am not putting my data into the cloud.  I talked to other “data” people and they all thought the same thing.  They might put their applications into the cloud, but not their data.   I started to think how might I achieve the benefits of  cloud technologies without handing my data over to an unknown provider.

So what makes a cloud a cloud?  I define a cloud as an infrastructure that provides high availability, self service, on-demand use and elasticity of resources.  Make sense? I thought not.  Lets break it down.

High availability is a term often used with a set of assumptions that can vary by person. For some people, high availability is just having good backups, but for others it means having geo-redundant systems that can fail over with no loss of data or downtime.  I define high availability within a single data center, meaning that I want to make sure if I have a hardware failure I am protected with no downtime or data loss.  However, if the data center is lost I am not protected.  In SQL 2012, I will expand my definition to include geo-redundancy.

I run a large environment with very little staff, so it is important that I empower my users and developers to do as much on their own as possible, so I can focus on what is important.  I would rather enable a system to allow users to spin up SQL Servers and databases on their own, than waste my time doing a repetitive task.  However, I want to be able to control how the users spin up servers and databases, which brings us to on demand use of resources.

I want the system to be able to determine when a new SQL Server is needed or when space needs to be added to a drive own its own rather than have to monitor and react.  This requires a lot of data collection and understanding of SQL Server workloads.  For some resources this is quite basic,  I want my servers to run at max of 80% of CPU.  So when a server is running at an average of 50% CPU,  I will stopping adding databases to the server, and spin up a new server instance.  Since this is a process I can define, thus I can automate it.

Elasticity is not only hard to define, but hard to implement and one of the attributes that is most desirable.  Everyone has systems that need a ton of resources at once  but only periodically; the rest of time the hardware is just being wasted.  I wanted to be able shift resources to where they are needed most and when, but at the same time control an unexpected load from taking over a server.  I want to be able to put a troublesome database in “Database Jail”.

With these concepts in mind, I thought I can achieve these benefits of the cloud, but do so within my own network.  Thus a private cloud is just a cloud with in a private network.

Coming up next….
The Benefits of Private SQL Clouds
The Architecture of Private SQL Clouds