ARCHITECTING MICROSOFT SQL SERVER ON VMWARE VSPHERE Best Practices Guide
Microsoft SQL Server® is one of the most widely deployed database platforms in the
world, with many organizations having dozens or even hundreds of instances deployed
in their environments. The flexibility of SQL Server, with its rich application capabilities
combined with the low costs of x86 computing, has led to a wide variety of SQL
Server installations ranging from large data warehouses with business intelligence and
reporting features to small, highly specialized departmental and application databases.
The flexibility at the database layer translates directly into application flexibility, giving
end users more useful application features and ultimately improving productivity.
Application flexibility often comes at a cost to operations. As the number of
applications in the enterprise continues to grow, an increasing number of SQL Server
installations are brought under lifecycle management. Each application has its own set
of requirements for the database layer, resulting in multiple versions, patch levels, and
maintenance processes. For this reason, many application owners insist on having a
SQL Server installation dedicated to an application. As application workloads vary
greatly, many SQL Server installations are allocated more hardware resources than
they need, while others are starved for compute resources.
These challenges have been recognized by many organizations in recent years. These organizations are now virtualizing their most critical applications and embracing a “virtualization first” policy. This means applications are deployed on virtual machines (VMs) by default rather than on physical servers, and SQL Server is the most virtualized critical application in the past few years. Virtualizing SQL Server with vSphere® allows for the best of both worlds, simultaneously optimizing compute resources through server consolidation and maintaining application flexibility through role isolation, taking advantage of the software-defined data center (SDDC) platform and capabilities such as network and storage virtualization. SQL Server workloads can be migrated to new sets of hardware in their current states without expensive and error-prone application remediation, and without changing operating system (OS) or application versions or patch levels. For high performance databases, VMware and partners have demonstrated the capabilities of vSphere to run the most challenging SQL Server workloads. Virtualizing SQL Server with vSphere enables many additional benefits. For example, vSphere vMotion®, which enables seamless migration of virtual machines containing SQL Server instances between physical servers and between data centers without interrupting users or their applications. vSphere Distributed Resource Scheduler™ (DRS) can be used to dynamically balance SQL Server workloads between physical servers.
vSphere High Availability (HA) and vSphere Fault Tolerance (FT) provide simple and reliable protection for virtual machines containing SQL Server and can be used in conjunction with SQL Server’s built-in HA capabilities. Among other features, VMware NSX® provides network virtualization and dynamic security policy enforcement. VMware Site Recovery Manager™ provides disaster recovery plan orchestration, vRealize Operations manager provides comprehensive analytic and monitoring engine, and VMware Cloud on AWS can be consumed to take the advantages of public cloud. There are many more benefits that VMware can provide for the benefit of virtualized applications. For many organizations, the question is no longer whether to virtualize SQL Server, rather, it is to determine the best architecture design to achieve the business and technical requirements while keeping operational overhead to a minimum for cost effectiveness.
1.1 Purpose
This document provides best practice guidelines for designing and implementing SQL Server in virtual machine to run on vSphere (further referenced as vSphere). The recommendations are not specific to a particular hardware set, or to the size and scope of a particular SQL Server implementation. The examples and considerations in this document provide guidance only, and do not represent strict design requirements, as varying application requirements might result in many valid configuration possibilities.
