Deciding to Virtualize SQL
The primary factor when deciding to virtualize SQL is the expected volume of read/write access. The biggest bottleneck when virtualizing SQL is typically disk I/O. Consider virtualizing SQL for development and test environments, and implement physical SQL Server for production environments to provide the best performance.
That said, the performance of virtualized SQL server has steadily improved and virtualization of SQL is becoming more common. If you decide to create a virtualize SQL cluster use SQL server 2012, Windows 2012 with Hyper-V and SCVMM for the greatest possible success and performance. Virtualizing SQL can allow for the easier transition to private or public cloud services like Azure when considering DR plans. To ensure a successful implementation do not overlook the details and follow configuration best practices.
To use SQL for Microsoft Dynamics CRM in Azure, you must have SQL Server running on a virtual machine. Currently CRM and Azure do not support running the CRM databases in Azure SQL Services. In addition, you can easily create multiple server environments or multitenant servers to have a development, UAT/testing, and production environments.
Best Practices when Virtualizing SQL
Here are some of the best practices when virtualizing SQL:
- Use a dedicated storage device utilizing iSCSI, SAS or Fiber
- Volumes should be spread across as many spindles as possible
- Limit the number of disks which share a volume
- Make sure to group similar disk operations together on the same spindles to avoid mixed I/O operations.
- Use fixed sized virtual disks as they provide better performance than dynamics disks. Dynamic disks are great for space savings, but have lower performance.
- Do not use virtual IDE disks for data and log storage; always use virtual SCSI disks for such storage.
- For CPU and memory start by basing your calculation off those you would make for a physical SQL server then add some for overhead. Stick to a 1:1 core relationship to vCPU.