When you need to reduce the number of database servers, the worst thing to do is just pile ‘em all onto one and hope it goes well. A successful virtualization or consolidation project involves a simple set of steps.
Inventory the existing SQL Servers and databases. In a perfect world, we’d already have an up-to-date inventory of every database on every server including its OS version, SQL version, security needs, HA/DR plans, performance requirements, and more. However, even good inventories are often missing a few key pieces required for a consolidation project – for example, compatibility lists for any third party vendor software installed on the server. If we’re hosting a database for an ISV application, we need to know what versions of SQL Server the vendor supports. I frequently see ISV apps that are no longer under maintenance or have been abandoned by the original manufacturer, and in those cases, we may not be able to move them onto a newer version of SQL. In the video at the end of this post, I cover some of the attributes you’ll need to inventory.
Categorize them into groups by attributes. After building our inventory, we can take a few steps back and look at similarities. If we’ve got a lot of ISV apps that still require SQL Server 2005, don’t need high availability, and aren’t performance-sensitive, we can group them together. If we find a lot of homegrown apps that are mission-critical and can’t wait to get onto the newest version of SQL Server, there’s another category. These groups of databases often pop right out of the list once we see the big picture.
Ask the right questions to the right people. Talk to the application owners (business users) of each database to find out more about their long term plans. When we need to merge multiple databases onto less servers, and we make our plans known to the business, we often discover hidden business requirements or budgets. You’d be surprised how often people make money available to keep their own hardware, or decide they’d like to abandon a database altogether rather than deal with upgrade requirements.
Choose a consolidation method to meet business needs. Some of our options include active/active clustering (also known as multi-instance clustering), virtualization, and cloud computing. Each one has its own pros and cons, and I discuss these in the video below.
Build the new environment and load test it. Before we run a single live production database on our newly created consolidation/virtualization hosts, we need to make sure they’ll be able to sustain as much throughput as possible. CPU, memory, storage, and network should all be tested using both off-the-shelf hardware synthetic testing tools like CrystalDiskMark and database testing tools like restoring your own databases and running known processes against them.
Plan the right migration method for each databases. We’ve got lots of options including copying the MDF/LDF files, doing a backup/restore, or performing log shipping or database mirroring to the new server. Log shipping and mirroring give us the ability to migrate databases with a matter of a few seconds downtime, but require more work and planning up front. Copying the MDF/LDF files or doing a backup/restore involves more downtime, but take less planning. It all comes down to business needs.
Test the plan, work the plan, and monitor metrics to ensure success. No matter what consolidation or virtualization method you pick, be very comfortable with your migration plan ahead of time. You’ve got a new set of servers for the transition – why not test your plan several times first to make sure it’ll work on go-live day? After the end users start logging in, know which performance metrics you’ll monitor to know if the app is working well or choking. Ideally, you’ll even have a plan to mitigate performance issues as they come up.
In this video from our Tech Tuesday Triage webcast series, I explain two of these steps – building an inventory and choosing a consolidation method:
Download the zipped spreadsheet and the PDF version of the PowerPoint slides mentioned in the webcast.
If you want help virtualizing or consolidating your SQL Servers, contact us. I’ve managed hundreds of SQL Server migration projects, and I’m completely comfortable helping businesses get out of end-of-lease hardware or out-of-support SQL Server versions.