This article is part of an Essential Guide, our editor-selected collection of our best articles, videos and other content on this topic. Explore more in this guide:
3. - SQL Server virtualization best practices: Read more in this section
- Considerations for virtualizing SQL Server
- Facts and myths about virtualizing SQL Server
- Strategies for maintaining high availability of virtual machines
- Creating SQL Server virtual appliances for Hyper-V
- Protecting virtual databases with database mirroring
Explore other sections in this guide:
Virtualizing applications like SQL Server can help an organization reduce costs. Furthermore, ever since Microsoft changed its SQL Server license model to a per CPU license model, it is possible to virtualize numerous instances of SQL Server on the same physical server. These licenses are costly, and therefore it is up to you to create a powerful host server that can run multiple virtual machines (VM) and SQL Server instances.
Organizations often run several different types of SQL Server databases. For example, many management products come with run-time databases which are deemed operational, and can -- and should -- be consolidated into a central location to reduce the amount of locations SQL Server engines run. You may also have production databases — databases which are tied to internal applications – which are deemed informational databases. Other types of databases include financial, organizational, departmental and geographical.
While each database is important to your organization, not all of them require the same level of protection. As a result, it's a good idea to use internal SQL Server features like database mirroring, a tool that provides protection for critical databases running in VMs (see Figure 1).
Figure 1 (Click to enlarge)
Database mirroring applies fault tolerance at the database level and automatically duplicates all of the contents of a database into another SQL Server installation. It will also automatically change over to the secondary database if the primary database is not available.
The mirrored database can also be used to provide additional functionalities, like reporting services. You can even perform backups from the mirrored copy, avoiding any performance impacts on the production database.
Since your databases have different protection requirements, you can use other, non-critical database engines from different VMs to protect important data.
Furthermore, database mirroring does not require special hardware or software tools, as databases can be mirrored from one SQL Server VM to another. In the event of a host server failure -- or even a VM failure -- users are automatically redirected to the mirror database with little or no service interruption.
If you decide to run database mirroring in your VMs, you should not make the virtual machines highly available through host server clustering. Otherwise the host cluster will restart the VM in the case of a failure. This could cause two versions of the same database to be live on the your network -- something to avoid at all costs.
Overall, features like database mirroring allow you to mix and match the types of databases you run in VMs. This lets you reduce costs while centralizing all of your SQL Server installations and providing protection for the databases that run your most critical data.
SQL SERVER AND MICROSOFT HYPER-V
Part 1: Creating fault tolerant installations
Part 2: Maintaining high availability
Part 3: Protecting virtual databases
Part 4: Creating virtual appliances
Part 5: Deploying virtual appliances
ABOUT THE AUTHORS
Danielle Ruest and Nelson Ruest are technology futurists focused on datacenter optimization and continuous service availability. They are authors of multiple books, notably "Training Kit 70-652: Configuring Windows Server Virtualization with Hyper-V" published by Microsoft Press and "Virtualization, A Beginner's Guide" published by McGraw-Hill Osborne. For more tips, write to them at email@example.com.