In early 2001 I worked @ a start-up company with about 150 people. I call it a start-up because it had no revenue but did have free breakfast, lunch and dinner. @ the company there were five people named Michelle and six named Dan (including yours truly). One day the VP of operations got confused about which Michelle and Dan he was talking about; he followed it with the following comment – you can’t swing a dead cat around here without hitting a Dan or a Michelle. Ok, I apologize to all cat lovers – I’m one myself and I for sure don’t condone the swinging of dead animals, or live ones for that matter. But I feel the same way about virtualization and consolidation. Hardly a days goes past when I’m not in a conversation about these topics. It’s important to remember that while virtualization has a coolness factor I recommend you approach it as an enabler to meeting business objectives and not the silver bullet that’ll solve all your woes. Also, while virtualization and consolidation are often mentioned in the same breath they’re not the same thing. A couple of guys on my team put together the following graphic to discuss SQL Server consolidation options:

image 

As you move left to right across the picture you move from Higher Isolation (which equates to higher cost) to Higher Density (which equates to lower costs). High isolation refers to resource and security isolation. Obviously you could take this to the extreme and have each application (instance of SQL Server) reside on its own hardware sitting in its own data center residing in its own building on its own power grid. But that’s crazy, right? Higher density means the greatest sharing of resources.

Here’s a brief explanation of each lane:

  1. IT Managed Environment: This solution is the most expensive but provides the greatest level of isolation. Each application is placed on dedicated hardware (computers, storage, and possibly network.)
  2. Virtual Machines: The next level provides terrific OS and application isolation – each application (SQL Server Instance) runs in it’s own VM. Multiple VMs can run on the same physical machine and resources of the physical environment can be allocated to each VM.
  3. Instances: Multiple instances of SQL Server can be installed on the same computer. While the resources (CPU, Memory, etc) of the computer are shared between the instances, each instances provides a very high degree of security isolation: each instance can have a different administrator.
  4. Databases: A single instance of SQL Server can house multiple databases. There’s a strong security boundary between databases (a database user can be contained to that database) but the database are sharing system resources and the administrator for the instance will have access to all databases.
  5. Schemas: Within a single database each database object (tables, views, stored procedures, etc) is contained within a schema. The database can have multiple schemas. Similar to how database acts as a security boundary, permissions can be granted on schemas and schema-contained securables, e.g. tables.

The main point here is there is no one size fits all solution or technology and virtualization is just one of the ways to meet consolidation needs. You will likely employ multiple solutions within your environment with the key being to chose the right technology to meet the business requirements of the application. As an IT professional it’s your job to understand the technology and how to apply that technology to solve business problems.

There are several different models out there for approaching consolidation. The high-level steps that resonate with me are:

  1. Plan: define the business and technology objectives. Define the boundaries of the project. Identify the key stakeholders and sponsors. Define the timeline.
  2. Inventory What You Have: there are many tools out there for creating an inventory of your technology assets. The Microsoft Assessment & Planning Toolkit does this and it’s free.
  3. Track How Things Are Being Used and Identify Consolidation Candidates: you can’t start throwing applications together without understanding their usage model.
  4. Consolidate: Once you’ve identified the candidates, make the changes. This will require a lot of up front planning to determine when apps can be moved (planned downtime) and the impact to the great app ecosystem. Remember, database connection strings will change.
  5. Track How Things Are Being Used: yes this is a repeat of step 3 but it’s important. You may get some thing's wrong (over consolidation) and you’ll need to make adjustments. Plus if your environment is like any I’ve seem it’s pretty dynamic with new applications popping up.
  6. Post Mortem: get the project team and key stakeholders together and discuss what went well and want didn’t. Document this learning so you’ll have it the next time around. Consolidation isn’t a one time event. You will need to constantly monitor your environment for opportunities.

 Finally, I couldn’t end this article without mentioning my favorite virtualization related features in Win7 and Win2K8 R2:

Virtualization and consolidation are concepts that have been around for at least 30 years. With the ever increasing pressure on IT to do more with less they are realities that can no longer be ignored. As I mentioned in my opening blog post, one of the challenging aspects of my job is I’m always thinking one to two releases out and I’m talking these days a lot about consolidation and virtualization… The first of this wave of capabilities sees the light of day with SQL Server 2008 R2 Application and Multi-Server Management.

Cheers,
Dan