Virtualizing SQL

How to implement on virtual infrastructure to maximize

performance and HA

The Golden Rule

• Design considerations for SQL workloads are essentially the same between physical and virtual environments now– vCPU can perform the same as CPU now, even virtual

multi-core sockets– If guaranteed I/O SLA is demanded, dedicated disks can be

provisioned to virtual infrastructure just as easy as physical (easier in most cases). Storage vMotion means you can always adjust later completely transparent to SQL

– Virtual memory is always backed by physical memory unless a cluster in under pressure. So vRAM is no different from RAM as long as you are not overprovisioning your virtual infrastructure

Base Advantages of Virtualized SQL

• High Availability – Provides all SQL VMs with an inherited cluster-like ability, without any

of the headache(when SLA’s do not require very low RTO)

• Snapshot– Ability to snapshot prior to major changes (ie: Windows updates)

allows for faster rollback (to that point in time)

• Flexibility– Easily increase memory or CPU to meet periodic demand spikes. End

of month activities, or periods of high usage for front end applications

• Portability– Move workloads/servers to higher-power hosts without interruption

of service. Refresh hardware without reinstall. Provides for easier and more plentiful disaster recovery options

The Way Virtualization Used to Be

• Old drawbacks – Anemic VMs from a SQL perspective– Storage

• Response times could get worse

• Throughput could be decreased

– Compute• Lack of memory

• Lack of vCPU

– Cost• Consolidation ratio blown. Host memory density not worth it

Multi-Vendor Virtualization Today

• New strengths– Storage

• 2TB disk size, 60 SCSI targets per VM• Improvements in storage. much better latency on storage and IO, up to 1 million IOPS

from a single VM with vSphere 5.1! • Server-side flash storage - great fit for tempdb. low persistence but high utilization.• New technologies in storage can enable SQL admins to gain access to persistent flash

based storage to store things like index data files (separate them into different file groups) identify heavily read-only content and you can move it into flash. Hybrid flash is the future

• EMC Fast Cache as an example

– Compute• More CPU , up to 64 vCPU for a single VM • More RAM , up to 1TB for a single VM

– Cost• Much lower price, economy of scale kicking in• Consolidation ratio good. Host memory/CPU density has increased massively. 384 GB+

RAM in a single 2 socket blade is common

SQL Workloads

• OLTP– High volume web back-ends

– High IOPS requirements throughout the day• Plan for peak daily activity

– CPU contention may require more vCPU per VM, especially on poorly optimized (front end) systems.

– Pro-tip : web application developer <> SQL developer in most cases. Poorly coded queries can shred a virtual SQL instance just as easily as a physical. Virtual vsphysical doesn’t change your DBA hat.

– Dynamically scale based on known demand peaks

SQL Workloads

• OLAP– Data warehouse

• Predictable high volume workloads

• Just like a physical server, daily ETL jobs will crush the disk. This is not an artifact of virtualization, just the nature of the job.

• Easier to dynamically scale a server for EOY operations. Add CPU/Memory when needed and remove when not required.

• Storage DRS can adapt workloads to appropriate storage dynamically.

– Reporting services• Treat like a web server (since that is essentially what it is)

When is it not a good idea to Virtualize?

• Vendor support – Number 1 case that precludes virtualizing a database

workload– Internal assessment of risk and maintenance of a

parallel physical test environment to satisfy Vendor requirements (reproduce an issue in the physical test environment)

• Ultra-low latency/Custom hardware requirements (example Stock market)– Not many real-world examples that people will often

run into.

Licensing

• SQL 2012 as point of reference. Individual VM vsHost licensing

• Individual VM licensing– Core license model

• 1 core license per virtual CPU/thread – Hyper-threading counts!!

• Sold in 2-packs• Minimum of 4 core licenses per VM

– Server/CAL licensing– Still present for standard edition– Only present for Enterprise edition if you currently have an active

SA contract on your Enterprise Ed. Server/CAL licenses– Can run maximum of 4 servers per host on Enterprise

Licensing

• License mobility– Any SQL license with SA on it can move to different

physical hosts as the VM moves.– Available for both per-core and Server/CAL models

• Dense virtualization licensing• License all of the physical processors on a host and you can

spin up unlimited virtual SQL servers (with SA on your licenses)

• Great fit for environments with large number of SQL servers• Can carve out either dedicated SQL clusters, or VM affinity

rules for the group of SQL servers to only run on a group of hosts.

VM Configuration

• TEMPLATE– Best thing you can do is to create a standard SQL VM

template that is tweaked (and documented!) to high heaven

– Reduces deployment time to approximately an hour, even with some post-patching

– Consistent high performance design reproduced throughout the environment

– Allows you to set the standard but still let virtualization administrators to deploy SQL VMs for you

VM Configuration

• Memory considerations

– SQL and OS side tweaks

• “Lock pages in memory” permission for SQL service account

• Set SQL max memory to 1-2GB less than OS memory

• Rough Rule of thumb, under 8GB of memory = 1GB reserved for OS. More than that = 2GB reserved for OS.

– Vmware Reservation for full memory amount– Critical if you use lock pages in memory tweak, but important to

use regardless.

– This is one of the real legitimate uses of memory reservations! Don’t be afraid to ask for it!

VM Configuration

• CPU considerations– SQL tweaks

• Set Max Degree of Parallelism (MDOP) to be equal to the number of vCPU assigned to the VM

• Split TempDB into a number of files equal to the number of vCPUassigned to the VM. This will optimize access to TempDB

– VMware tweaks• Start with a single vCPU in your template.

– Easier to go up to the multiprocessor HAL than come back down again

– All virtual resources have overhead, less is more. Only assign what you really need.

• Remember that you can now create multi-core vCPU sockets. This can have licensing implications.

VM Configuration

• Network considerations

– VMTools and VMXNET 3

– VMXNET 3 NIC driver is bundled into VMTools.

– Ensure the latest version of VMTools is included in your template

– SIGNIFICANT performance advantage over default E1000 virtual NIC driver (TCP offloading), especially when using 10 Gb NICs in the hosts.

VM Configuration

• Storage considerations

– Sensitive workloads: design backend storage like you would for physical SQL

– For SQL VM’s with low performance reqs: design backend storage like you would for other server VM’s

VM Configuration

• Storage Protocols– FC / FCoE

• Stable, consistent, reliable. We prefer FC vs IP based storage protocols when discussing SQL (and other business critical apps)

– iSCSI• Easy to start, but more complex than FC to do right• You don’t need Jumbo Frames, that’s to reduce CPU and we

have plenty of CPU

– NFS• No true multipathing (yet)• Does not support RDMs, so capped at 2 TB for a volume• Scales out very well

VM Configuration

• FC vs iSCSI

– Fibre Channel – similar to railways

• Purpose built, connected to predetermined specific endpoints.

• Predictable performance

– iSCSI – similar to highways

• Can be more flexible

• Endpoints are simple to add

• Traffic, latency can be a problem

VM Configuration

• RDM vs VMDK

– Performance is near identical. Very, very small performance hit for VMDK

– VMDK is much simpler to use

– VMDK is <still> limited to just under 2 TB

– RDM is required for Physical to Virtual failover clusters

– RDM is required for array based snapshot and backup applications

VM Configuration

• VM SCSI controllers

– Use multiple SCSI controllers to allow parallel I/O operations (max of 4)

– Separate controller for OS, data files, transaction log files

– Queue depth – default is usually fine, engage your storage team and vendor before adjusting. Lots of knobs and dials here.

VM Configuration

• Paravirtualized SCSI controllers

– Recommended for new SQL VM’s that are storage performance sensitive

– Will require loading the mass storage driver during Windows if used for the system drive (use a template!)

– About 2000 IOPS from the VM is when it starts to make a difference

VM Configuration

• Partition alignment - host:– In vSphere 5.X, VMFS is aligned at the 1 MB mark, this

is fine

• Partition alignment - guest:– Align guest partitions, usually 1 MB is good (use a

template!)

• Create VMDK files as Eager Zeroed Thick– You don’t want write I/O’s waiting for the .vmdk to be

zeroed

– VAAI enabled storage arrays will speed this up

Using PCIe SSD Cards• I/O Latency measured in microseconds instead of

milliseconds• EMC XtremeSF, FusionIO, others. Does not require a

specific storage array.• Manually place tempDB here, for example, or other non-

unique data (mirrored at the application level, for instance)• Software enables using local SSD as an extension of storage

array cache. Can be used for unique data, reads are accelerated and writes are handled by the storage array (EMC XtremeSW)

• Or use SQL Always-On to protect data, allowing unique data to be written to local SSD

• Will affect vMotion (and therefore DRS), but SQL Always-on can mitigate

VM Configuration

Backup Strategy

• Choice between Host based application aware VM backups, and traditional SQL maintenance plan backups– Must choose an approach for Full Recovery Mode, as each one

wants to have control over the backup chain, and you do not want to risk both truncating the transaction log

– Host based appropriate for single daily backups– SQL Maintenance plan preferred for “point-in-time” type restore

SLA– Must adjust either strategy no matter which is chosen. Neither

can do the whole job, so both must be used

• Backup admins will have policies configured to groups of VMs. You must ensure SQL VMs are designated as a separate backup group so policies can be tweaked no matter what choices are made

Backup Strategy

• Host based application aware backups– Whole VM backup that will truncate SQL/Exchange

Logs when the job is run

– Utilizes VM snapshots to freeze disk IO while the backup is run

– Provides a crash consistent backup. Rollbacks may occur when databases are brought online

– Appropriate for workloads that have a single daily backups SLA

– Ensure your databases are in Simple recovery mode not Full, to keep transaction log size down

Backup Strategy

• SQL Maintenance plan backups

– Still useful for index and statistics and general maintenance work around the database, even if Host based backups are used

Virtual SQL Clustering and HA

• Traditional clustering– Very much still available. 5 node cluster max with

vsphere 5.1

– vMotion and Storage vMotion not allowed. HA not impacted

– Virtual/Physical hybrid clustering possible

– Some restrictions on allowed storage protocols

– Does not make traditional clustering any less painful

– Does allow for a cultural transition from physical to virtual more palatable for some

Virtual SQL Clustering and HA

Virtual SQL Clustering and HA

• SQL Always-On clustering– Best of both worlds!

• Essentially get clustering without shared storage requirement or headaches normally found in MSCS clusters

• No shared storage = less money with no loss in stability/performance

– Super-fast failover you get from SQL Mirrored databases without SQL NCLI (or .NET data connector) requirement.• Fails groups of databases over together

• Works great even for legacy apps that use old ODBC/JDBC drivers

Virtual SQL Clustering and HA

• SQL Always-On clustering– Based on proven technologies

– Windows Failover Clustering– SQL Mirroring– Exchange DAG similarity

– Lagged nodes allow for cheap off-site DR capacity– Read-intent queries

• Automatically offload certain query types to a read-only node

– Backups can run on secondary copies• Can specify preference for where backups run. Maintenance

plans are intelligent and know if another node is running a backup. Can leverage this intelligence in scripts as well.

Virtual SQL Clustering and HA

Video demonstration of

Always-on failover

Virtual SQL Clustering and HA

• Site Recover Manager – Offsite replication and recovery options

– Protects entire virtual infrastructure including SQL

– Can provide close to 0 RPO and very low RTO

– Scripted DR recovery means critical SQL servers can come up first. VM “importance” preference. Critical for SQL workloads that are often back-ends for other systems.

Take-away’s for the DBA’s• Use a TEMPLATE!!

– Seriously build a SQL VM template– Building a template is great….updating a template

twice a year at least is better

• vCenter access – Performance stats over time– Console access to VM’s (virtual KVM access)– Event history– Capacity planning– Security concerns from VM Admins can be handled by

granting read-only access to the DBA

Take-away’s for the DBA’s

• More <> better

– Often times overprovisioning virtual resources can actually mean worse performance. Don't ask for more than you need

– Start with single vCPU in your template. Easier to go to SMP than to go back to single proc. Single VM reboot to add vCPU’s for SMP.

– Remove extraneous devices, CD-Rom, ISO’s, Floppy, anything that is not needed for clean operation.

• You can always add things on temporarily if needed

Links

• Always-On Failover Demonstration – Kyle Quinby, Varrow• MS KB 920093 - Tuning options for SQL Server when running in high

performance workloads• MS SQL 2012 license guide for virtualization• VMw KB 1037959 - Microsoft Clustering on VMware vSphere: Guidelines

for Supported Configurations• VMware's SQL Server Best Practices Guide• When to use Lock Pages in Memory with SQL Server• How to Enable the Lock Pages in Memory Option• VMware - 1 Million IOPS on 1 VM• VMw KB 1010398 - Configuring disks to use VMware Paravirtual SCSI

(PVSCSI) adapters• VMw KB 1022242 - Types of supported Virtual Disks on ESX/ESXi hosts