Consolidation by definition is the process of combining multiple SQL Server Databases & Servers running on different machines (could be geographically separated) onto a smaller number of more powerful machines in a central location. However in my opinion regarding SQL, its a process of getting organized, spending for what you need or use, and off-course saving at the same time. Lets see how consolidation and virtualization works together?
Microsoft SQL Server since beginning is overall self maintaining, secure by default and self tuning DBMS that requires a very little or basic configuration during installation or later during usage, In a large Enterprise size organization its easier adaptability and usage can lead into uncoordinated installations, wasted hardware and licenses, lack of standards and security holes.
Think Again! You should consider adopting Virtualization and Consolidation technique if you have similar questions:
-
Looking by your SQL Server inventory list, you realized that number of SQL servers are going up every month?
-
Looking by server utilization reports, you realized that your team or vendor over estimated database server hardware requirements and workload; leading into buying excessive hardware that your application is never going to use?
-
Every time it take months to plan & implement SQL patching, upgrades, installation etc, Applying SQL Server best practices and security updates/settings are complex and far of reach.
Better together Approach: You can consider three best possible scenario to implement, but are having its own benefits and concerns.
-
One OS/One SQLinstance- multiple databases
Its the best that you can get, in simple words evaluate your application that uses a few database(s); move your databases to a shared database server. Concerns: shared cache, SA permission, similar name databases or objects and logins, maintenance window, remote desktop connection (rdp) etc -
One OS/Multiple SQL Instance
Build a server having multiple SQL Server instances for applications that require its own unique collation, SQL version & build, own dedicated memory/cache, tempdb etc. Concerns: SA permissions, remote desktop etc. -
One OS/One SQL Instance (virtualization)
For applications having extreme performance needs and unique set of configurations. build a server with multiple virtual Operating systems and each OS running SQL Instance.
Software dependency: Microsoft Hyper-V, VMware, hp polyserve etc
Consolidation & Virtualization benefits
Concern(s):
Milestones to Destination
- Is it a vendor supported/provided SQL Instance with limitations or internal home grown application? and what is workload or capacity planning guidelines for future.
- Any significant reason a physical server is required? or why physical to virtual (P2V) should not be done?
- Can Databases’ from SQL Instance be clubbed/consolidated with other SQL Instance? what is frequency of database changes/deployment or downtime requirements.
- Can SQL instance be upgraded to latest SQL Server version & build? as per virtualization standard in your environment?
- What are high availability options implemented for the databases & SQL Service?
Best practices:
- Its better to divide entire SQL Server inventory into multiple smaller sections. Example- Should look at creating 5 subset of 100 servers rather than going in for virtualization of all 500 servers in a single attempt. Apply learning, experiences and best practices in later subsets.
- Use single machine with individual SQL Named Instance or VM for Production/Test/Development/Staging db requirements. (depends on application/environment)
- Never ever, oversubscribe resources for your server on virtual platform
- Calculate total server workload in virtualization model with real-time application and database workload in different scenario or timings.
- Carefully choose virtualization technique and server hardware to implement
