Microsoft SQL Server is one of the most widely deployed “apps” in the market today and is used as the database layer for a myriad of applications, ranging from departmental content repositories to large enterprise OLTP systems. Typical SQL Server workloads are somewhat trivial to virtualize; however, business critical SQL Servers require careful planning to satisfy performance, high availability, and disaster recovery requirements. It is the design of these business critical databases that will be the focus of this breakout session. You will learn how build high-performance SQL Server virtual machines through proper resource allocation, database file management, and use of all-flash storage like XtremIO. You will also learn how to protect these critical systems using a combination of SQL Server and vSphere high availability features. For example, did you know you can vMotion shared-disk Windows Failover Cluster nodes? You can in vSphere 6! Finally, you will learn techniques for rapid deployment, backup, and recovery of SQL Server virtual machines using an all-flash array.

1. Advanced SQL Server on vSphere
Scott Salyer, VMware, Inc
Wanda He, EMC
VAPP5598
#VAPP5598

2. • This presentation may contain product features that are currently under development.
• This overview of new technology represents no commitment from VMware to deliver these
features in any generally available product.
• Features are subject to change, and must not be included in contracts, purchase orders, or
sales agreements of any kind.
• Technical feasibility and market demand will affect final delivery.
• Pricing and packaging for any new technologies or features discussed or presented have not
been determined.
Disclaimer
CONFIDENTIAL 2

3. The Percentage of Applications in Virtualized Infrastructure
Has Increased Dramatically over the Last Few Years
(VMware Core Metrics Survey July 2015)
CONFIDENTIAL 3
Microsoft SQL is the most common application running in on-premise virtual infrastructure
NA EU dAP BRIC SMB COMM ENT
57% 73% 70% 74% 68% 71% 64%
47% 51% 39% 56% 43% 51% 54%
41% 43% 46% 61% 36% 46% 57%
45% 54% 37% 41% 43% 49% 46%
34% 38% 59% 51% 37% 39% 48%
26% 27% 32% 37% 24% 34% 33%
25% 30% 23% 35% 16% 30% 39%
29% 16% 31% 27% 22% 22% 30%
15% 23% 30% 28% 19% 24% 25%
15% 22% 22% 30% 17% 21% 25%
71% 62% 62% 64% 65% 64% 68%
48% 54% 49% 55% 50% 51% 53%
51% 45% 49% 49% 44% 49% 53%
36% 35% 39% 46% 37% 40% 37%
20% 15% 20% 26% 15% 17% 25%
600 450 230 323 653 346 604
Region Company Size
67%
49%
46%
45%
42%
29%
28%
25%
22%
21%
66%
51%
49%
38%
19%
Microsoft SQL
Microsoft SharePoint
SAP
Microsoft Exchange
Oracle Databases
Oracle Applications
High Performance Computing
Custom BCA/ industry-specific
Oracle Middleware
IBM Middleware
Business critical
Important
Development
Test
Staging
 Applications in Virtualized Infrastructure
> Total
< Total
N = 1603
 Level of Criticality of Applications in Virtualized Infrastructure
(Select all that apply)
(Select all that apply)

4. Virtualizing Applications
Sessions and Offerings
• 30 Breakout Sessions with 5 Panels & 4 Quick Talks
• 10 Group Discussions
• One-on-One Meet the Experts Sessions
• Checkout the Hands on Labs
Sign up for the Independent Oracle User Group
(IOUG) VMware Special Interest Group (SIG)
www.ioug.org/vmware

5. RDBMS Books from VMware Press
CONFIDENTIAL 5
Book signing @ 1PM
Tuesday Sept 1
vmwarepress.com
http://www.pearsonitcertification.com/store/virtualizing-oracle-databases-on-vsphere-9780133570182
http://www.pearsonitcertification.com/store/virtualizing-sql-server-with-vmware-doing-it-right-9780321927750

6. Agenda
CONFIDENTIAL 6
1 Introduction – Why Virtualize SQL Server?
2 Designing for Performance
• Storage Design
• Memory Optimization
• NUMA Considerations
• ExtremeIO Enhancements
• Monitoring and Troubleshooting
3 Consolidating Multiple SQL Server Workloads
4 SQL Server Availability

7. Introduction
Why virtualize SQL Server?

8. Quick Facts
• SQL Server database servers account for ~10% of all x86 workloads and are typically
underutilized (6-20% CPU utilization)
• Many Database Administrators (DBAs) are hesitant to virtualize database servers due to
perceived issues with performance, availability, and licensing
• Running SQL Server workloads on vSphere can help to reduce physical server and
licensing costs while increasing availability without sacrificing performance
• The VMware SDDC platform offers management benefits that extend to both the infrastructure
administrator and the DBA
– In-depth application monitoring and trend analysis
– Automation and provisioning of database components for developers (self-service)
– Application and site-resiliency
CONFIDENTIAL 8

9. Reduce hardware costs by > 50%
• Consolidate servers by 4X – 20X
Provision databases on demand
• Minutes to provision in production and in the lab
Reduce licensing costs
• Potentially increase utilization of SQL Server licenses
(depending on degree of consolidation)
Increase application Quality of Service
• Scale dynamically
• Built-in high availability and simple disaster recovery
DB On Demand
Quality of Service
DB Consolidation
Why Deploy SQL Server on VMware SDDC?
CONFIDENTIAL 9
Licensing
Complete isolation between systems on the same host
• Protects databases and applications against network-based threatsSecurity

10. Designing for Performance
Tier-1 Production Workloads

11. Storage Design

12. Factors Affecting Storage Performance
CONFIDENTIAL 12
vSCSI adapter
Application
VMKernel
FC/iSCSI/NAS
VMKernel admittance (
Disk.SchedNumReqOutstanding)
Per path queue depth
Adapter queue depth
Storage network (link speed,
zoning, subnetting)
HBA target queues
Array SPs
# of disks
Disk queue depth
Adapter queue depth
Adapter type

13. Optimize for Performance – Queue Depth
• vSCSI Adapter
– Be aware of per device/adapter queue depth maximums (KB 1267)
– Use multiple PVSCSI adapters, follow KB 2053145 for large-scale IO intensive SQL deployment (not applicable for
typical deployment)
• VMKernel Admittance
– VMKernel admittance policy affecting shared datastore (KB 1268), use dedicated data store for mission critical SQL
Server
– VMKernel admittance changes dynamically when SIOC is enabled (recommended for lower-tier SQL Server
deployments)
• Physical HBAs
– Follow vendor recommendation on max queue depth per LUN (http://kb.vmware.com/kb/1267)
– Follow vendor recommendation on HBA execution throttle
– Be aware settings are global if host is connected to multiple storage arrays
– Pick the right multipathing policy based on vendor storage array design
CONFIDENTIAL 13

14. Optimize for Performance – Storage Network
• Link Type/Speed
– FC vs. iSCSI vs. NAS
– Latency suffers when bandwidth is saturated
• Zoning and Subnetting
– Place hosts and storage on the same switch, minimize ISL
– Use 1:1 initiator to target zoning or follow vendor recommendation
– Enable jumbo frame for IP based storage (MTU needs to be set on all connected physical and
virtual devices)
– Make sure different iSCSI IP subnets cannot transmit traffics between them
CONFIDENTIAL 14

15. VMDK Lazy Zeroing*
• Default VMDK allocation policy lazy zeroes 1M VMFS
blocks on first write
• Write penalty on an untouched VMDK
• SQL Server operations could be affected by lazy zeroing
– Write operations
– Read operations that use tempdb extensively
– Bulk load/index maintenance
• For best performance, format VMDK as eagerzeroedthick *
* Zero offload capability in VAAI improves zeroing in
supported arrays
CONFIDENTIAL 15
0
20
40
60
80
100
120
140
160
180
200
1 host 2 hosts4 hosts8 hosts 16
hosts
Throughput(MBps)
Effect of Zeroing on
Storage Performance
"Post-zeroing" "Zeroing"
Choose Storage which supports VMware vStorage
APIs for Array Integration (VAAI)

16. SQL Server Data Files
• For optimal performance, dedicate data stores / LUNs to Data, TempDB, and Log files
– Defaults place data and logs on the same volume…change with ALTER DATABASE -> MODIFY FILE statement
– Data and TempDB files can share the same data store / LUN but dedicate a LUN to Log files
– Stripe data across as many physical spindles as possible
• Use multiple TempDB files – start with 1 TempDB file per CPU core (up to 8)
– Files should be of equal size – SQL Server favors allocations in files with more free space (hot spots)
• Number of Data files will depend on the size of the database and backup considerations
– Or alternately .25 Data files per CPU core
• If using storage tiering use the following file placement priority – fastest to slowest drive:
– TempDB Data Files > Transaction Log Files > Data Files
• Use RAID 10 for log, use RAID 10 or RAID 5 for data, tempdb (not applicable to XtremIO)
CONFIDENTIAL 16
Follow Microsoft and Storage Vendor Recommendations!

17. Strict Best Practices SQL Server VM Disk Layout Example
Characteristics:
• OS on shared DataStore/LUN
• 1 database; 4 equally-sized data
files across 4 LUNs
• 1 TempDB; 4 (1/vCPU) equally-sized
tempdb files across 4 LUNs
• Data, TempDB, and Log files spread
across 3 PVSCSI adapters
– Data and TempDB files share PVSCSI
adapters
• VMDK/DataStores could be RDMs
Advantages:
• Optimal performance; each Data,
TempDB, and Log file has a
dedicated VMDK/Data Store/LUN
• I/O spread evenly across PVSCSI
adapters
• Log traffic does not contend with
random Data/TempDB traffic
CONFIDENTIAL 17
NTFS Partition:
64K cluster size
C: D: H: E: I: L: T:
DataFile1
.mdf
DataFile5
.ndf
LogFile1.
ldf
TmpLog1
.ldf
OS
ESX Host
LUN1
Data Store 1
VMDK1
LUN2
VMDK2
LUN3
VMDK3
LUN4
VMDK4
SQL ServerOS
Can be placed on
a DataStore/LUN
with other OS
VMDKs
Can be Mount Points under a drive as well.
OS VMDK
Can also be a shared
LUN since TempDB
is usually in Simple
Recovery Mode
PVSCSI1LSI1
F: J: G: K:
TmpFile1
.mdf
TmpFile2
.ndf
TmpFile3
.ndf
TmpFile4
.ndf
Data Store 2 Data Store 3 Data Store 4
LUN5
VMDK5
LUN6
VMDK6
Data Store 5 Data Store 6
LUN5
VMDK5
LUN6
VMDK6
PVSCSI2
Data Store 5 Data Store 6
LUN5
VMDK5
LUN6
VMDK6
PVSCSI3
Data Store 5 Data Store 6
DataFile3
.ndf
DataFile7
.ndf
Disadvantages:
• You can quickly hit the ESX LUN Limit!
• More complicated storage management

18. Realistic SQL Server VM Disk Layout Example
Characteristics:
• OS on shared DataStore/LUN
• 1 database; 8 Equally-sized data files
across 4 LUNs
• 1 TempDB; 4 files (1/vCPU) evenly
distributed and mixed with data files
to avoid “hot spots”
• Data, TempDB, and Log files spread
across 3 PVSCSI adapters
• VMDK/DataStores could be RDMs
Advantages:
• Fewer LUNs used
• I/O spread evenly/TempDB
hot spots avoided
• Log traffic does not contend with
random Data/TempDB traffic
CONFIDENTIAL 18
NTFS Partition: 64K
cluster size
C: D: E: F: G: L: T:
DataFile1.mdf
DataFile2.ndf
TmpFile1.mdf
DataFile4.ndf
DataFile3.ndf
TmpFile2.ndf
DataFile5.ndf
DataFile6.ndf
TmpFile3.ndf
DataFile7.ndf
DataFile8.ndf
TmpFile4.ndf
LogFile.ldf TmpLog.ldfOS
ESX Host
LUN1
Data Store 1
VMDK1
LUN2
Data Store 2
VMDK2
LUN3
Data Store 3
VMDK3
LUN4
Data Store 4
VMDK4
LUN5
Data Store 5
VMDK5
LUN6
Data Store 6
VMDK6
SQL ServerOS
Can be placed on a
DataStore/LUN with other
OS VMDKs
Can be Mount Points under a drive as well.
OS VMDK
Can also be a shared
LUN since TempDB is
usually in Simple
Recovery Mode
PVSCSI1LSI1 PVSCSI2 PVSCSI3

19. Block Alignment
• Configure storage presented to vSphere hosts using vCenter to
ensure VMFS block alignment
• Misalignment can result in up to 50% performance hit
• Windows 2008+ should align sectors by default…double-check!
– http://msdn.microsoft.com/en-us/library/dd758814.aspx
– http://blogs.msdn.com/b/jimmymay/archive/2014/03/14/disk-partition-
alignment-for-windows-server-2012-sql-server-2012-and-sql-server-
2014.aspx (Jimmy May - MSDN Blogs)
• For example, OEM setups with recovery partitions could result
undesirable starting offsets for the Windows partition
CONFIDENTIAL 19
Unaligned partitions result in additional I/O
Aligned partitions reduce I/O
stripe unit size value should be an integer

20. Memory Optimization

21. Large Pages in SQL Server Configuration Manager (Guest)
• Use Large Pages in the guest
– ON by default in 2012/2014 if Lock Pages in Memory User Right is granted to SQL Server Service
Account (sqlservr.exe) and if the VM has 8+ GB of memory - http://msdn.microsoft.com/en-us/library/ms178067.aspx
– For older versions, start SQL Server with trace flag -T834
CONFIDENTIAL 21

22. NUMA Considerations

23. Non-Uniform Memory Access (NUMA)
• Designed to avoid the performance hit when several
processors attempt to address the same memory by
providing separate memory for each NUMA Node.
• Speeds up Processing
• NUMA Nodes Specific to Each Processor Model
• Enable Non-Uniform Memory Access (NUMA) in BIOS
– ESXi is NUMA-aware and will schedule vCPUs onto a
single NUMA node (if it fits)
– SQL Server is NUMA-aware
CONFIDENTIAL 23

24. NUMA Best Practices
• http://www.vmware.com/files/pdf/techpaper/VMware-vSphere-CPU-Sched-Perf.pdf
• Avoid Remote NUMA access
– Size # of vCPUs to be <= the # of cores on a NUMA node (processor socket)
• Where possible, align VMs with physical NUMA boundaries
– For wide VMs use a multiple along with virtual NUMA
• Hyperthreading
– Initial conservative sizing: set vCPUs equal to # of cores
– HT benefit around 20-25%, < for CPU intensive batch jobs (based on OLTP workload tests )
• # of virtual sockets and # of cores / virtual socket: where possible keep default 1 core / socket
• ESXTOP to monitor NUMA performance in vSphere
– Coreinfo.exe to see NUMA topology in Windows Guest
• If vMotioning, move between hosts with the same NUMA architecture to avoid performance hit
(until reboot)
CONFIDENTIAL 24

25. Non-Wide VM Sizing Example (VM fits within NUMA Node)
• 1 vCPU per core with hyperthreading OFF
– Must license each core for SQL Server
• 1 vCPU per thread with hyperthreading ON
– 10%-25% gain in processing power
– Must license each thread for SQL Server
CONFIDENTIAL 25
“numa.vcpu.preferHT” to true to force 24-way VM
to be scheduled within NUMA node
SQL Server VM: 24 vCPUs
NUMA Node 0: 128 GB Memory
0 1 2 3 4 5 6 7 8 9 10 11
SQL Server VM: 12 vCPUs
NUMA Node 0: 128 GB Memory
0 1 2 3 4 5 6 7 8 9 10 11
Hyperthreading OFF Hyperthreading ON

26. SQL Server VM: 24 vCPUs
NUMA Node 0: 128 GB Memory
0 1 2 3 4 5 6 7 8 9 10 11
NUMA Node 1: 128 GB Memory
0 1 2 3 4 5 6 7 8 9 10 11
Virtual NUMA Node 1Virtual NUMA Node 0
Hyperthreading OFF
Wide VM Sizing Example (VM crosses NUMA Node)
• Extends NUMA awareness to the guest OS
• Enabled through multicore UI
– On by default for 8+ vCPU multicore VM
– Existing VMs are not affected through upgrade
– For smaller VMs, enable by setting numa.vcpu.min=4
• Do NOT turn on CPU Hot-Add
• For wide virtual machines, confirm feature is on for best performance
CONFIDENTIAL 26

27. XtremIO Enhancements

28. Common Challenges
• Consolidation creates random performance issues
• Copying data is common – VMs, databases, analytics
• Workflow complexity – downstream data services, lifecycle management
CONFIDENTIAL 28
MASSIVE OPPORTUNITY
FOR IMPROVEMENT

29. XtremIO All-Flash Storage Array with Rich Data Services
CONFIDENTIAL 29
Advantages for SQL Server:
 Scaling: Linear, Dynamic for Capacity & IOPs
 Performance: Consistent & Predictable at Scale
 Workflow: Zero Impact Copy Services
 Data-Reduction: In-line and Unstoppable
 Enterprise-Ready: Data Protection & Availability
 Simplicity: Zero Capacity Planning & Tuning
SCALE-OUT
CONSISTENT & PREDICTABLE
SUB-MS LATENCIES
DATA SERVICES
INLINE ALL THE TIME
MANAGEMENT SIMPLICITY
& AUTOMATION

30. Performance – Consistent Low Latency
• Consolidate 1, 2, 4, and 8 SQL
Server VMs
• DB size: ~1TB each
• XtremIO dual X-Brick
• OLTP like workload, 90% read,
10% write, majority 8K random
• Near linear scalability of IOPS
• Consistent sub-millisecond avg.
disk latency
CONFIDENTIAL 30

31. Performance – Increase Consolidation Efficiency
• Zero tuning performance
enhancement
• Reduce of batch run time from
7hrs to 1hr
• Opportunity to increase
consolidation density with more
efficient resource utilization
• Maximize return of investment on
SQL Server licenses
0
1
2
3
4
5
6
7
8
Traditional Storage XtremIO
BatchJobRunTime(hrs)
Before and After Customer Study
CONFIDENTIAL 31

32. Storage Efficiency
• “Zero” optimized
– Instant eagerzeroedthick
– Zero space for pre-allocated space
• Space efficient VM clones, database copies
• Automatic compression, full compatibility w/ SQL
native compression
PHYSICAL
CONFIDENTIAL 32
Database Size on VM = 1TB
Logical Volume = 610GB
Provisioned VMDK = 2TB
PHYSICALPhysical = 383GB
Thin Provision
Zero Optimized
Dedupe,
Compressed
5.3:1
Overall Efficiency

33. Simplicity – Capacity Planning and Operational Management
CONFIDENTIAL 33
DONE!
XTREMIO
Volume Size
RAID group/Number of spindles
Storage pool/tiering
Number of LUNs
Separate data vs. log
Tempdb placement
Separate OLTP vs. analytics
workloads
HISTORIC COMPLEXITIES
Right sizing: hot vs. active vs. cold

34. DESIGN / DEVELOPUPGRADE
TUNE
MAINTAIN
REPORTING
Backup
Test/Dev Copies
Offload Query Tuning
dbcc checkdb
App-Consistent Snapshot
Backup
Reporting Copies
Copy for Failback
Agility – Enhanced Lifecycle Management w/ Copy Services

35. Demo: Rapid Deployment of AlwaysOn
Secondary Replica

36. Monitoring and Troubleshooting

37. Performance Needs Monitoring at Every Level
CONFIDENTIAL 37
Application
Guest OS
ESXi Stack
Physical
Server
Connectivity
Peripherals
Application Level
App Specific Perf tools/stats
Guest OS
CPU Utilization, Memory Utilization, I/O Latency
Virtualization Level
vCenter Performance Metrics /Charts
Limits, Shares, Virtualization Contention
Physical Server Level
CPU and Memory Saturation, Power Saving
Connectivity Level
Network/FC Switches and data paths
Packet loss, Bandwidth Utilization
Peripherals Level
SAN or NAS Devices
Utilization, Latency, Throughput
START
HERE

38. Virtual
Machine
Storage
LUN
Physical
Disks
Guest OS disk
VMware
Data store
(VMFS
Volume)
.vmdk file
Storage Array
Logical Storage Layers: from Physical Disks to vmdks
CONFIDENTIAL 38
KAVG
• Tracks latency of I/O passing thru
the Kernel
• Investigation Threshold: 1ms
DAVG
• Tracks latency at the device driver;
includes round-trip time between
HBA and storage
• Investigation Threshold: 15 - 20ms,
lower is better, some spikes okay
Aborts (ABRT/s)
• # commands aborted / sec
• Investigation Threshold: 1
GAVG
• Tracks latency of I/O in the guest
VM
• Investigation Threshold: 15-20ms
KB Article Link:
http://kb.vmware.com/selfservic
e/microsites/search.do?langua
ge=en_US&cmd=displayKC&e
xternalId=1008205

39. In-guest SQL Server Performance Monitoring
• Perfmon
– SQL Server specific counters: SQLServer:**
– VMware Tools includes a Perfmon DLL that provides visibility into host CPU, memory, and disk usage
• SQL Server Extended Events: https://technet.microsoft.com/en-us/library/bb630282(v=sql.105).aspx
• SQL Server Profiler
– Monitor SQL Server performance at T-SQL statement level
• SQL Server Dynamic Management Views (DMVs)
– Monitor the internal health of SQL Server
– Sys.dm_*
• SQL server Replay https://msdn.microsoft.com/en-us/library/ff878183.aspx
CONFIDENTIAL 39

40. Consolidating Multiple SQL
Server Workloads

41. Consolidation Options
CONFIDENTIAL 41
• Scale-up approach
– Multiple instances per VM
– Fewer virtual machines
– More complex workload management
• Use Min Server and Max Server memory OR
Resource Governor
– Potential reduction in SQL Server licensing
cost
• Scale-out approach
– Single instance per VM
– Potential increase in mgmt. overhead
– Better isolation/performance
– Easier security and change mgmt.
– DRS more effective with smaller VMs
– Faster migration (vMotion)
41

42. Running with Mixed SQL Server Workloads
• Consider workload characteristics, and manage pCPU overcommitment as a
function of typical utilization
– OLTP workloads can be stacked up to a sustained utilization level
– OLTP workloads that are high usage during daytime and batch workloads that run during off-peak hours
mix well together
– Batch/ETL workloads with different peak periods are mixed well together
• Consider operational history, such as month-end and quarter-end
– CPU and memory Hot Add can be used to scale up VMs
– Additional VMs can be added to handle peak periods if scale out is a possibility
– Reduce virtual machine density, or add more hosts to the cluster
CONFIDENTIAL 42

43. OLTP vs. Batch Workloads
What this says:
• Average 15% Utilization
• Moderate sustained activity (around 28% during
working hours 8am-6pm)
• Minimum activities during none working hours
• Peak utilization of 58%
What this says:
• Average 15% Utilization
• Very quiet during the working day
(less than 8% utilization)
• Heavy activity during 1am-4am, with
avg. 73%, and peak 95%
Batch Workload (avg. 15%)
OLTP Workload (avg. 15%)
CONFIDENTIAL 43

44. SQL Server Availability

45. vSphere Availability Features
• vSphere vMotion
– Can reduce virtual machine planned downtime
– Relocate SQL Server VMs without end-user interruption
– Perform host maintenance any time of the day
• vSphere DRS
– Monitors state of virtual machine resource usage
– Can automatically and intelligently locate virtual machine
– Can create a dynamically balanced SQL deployment
• VMware vSphere High Availability (HA)
– Does not require Microsoft Cluster Server
– Uses VMware host clusters
– Automatically restarts failed SQL virtual machine in minutes
– Heartbeat detects hung virtual machines
– Application HA can provide availability at the SQL Server service level!
CONFIDENTIAL 45

46. Microsoft
Clustering on
VMware
vSphere
support
VMware
HA
support
vMotion
DRS
support
Storage
vMotion
support
MSCS
Node
Limits
Storage Protocols support Shared Disk
FC
In-
Guest
OS
iSCSI
Native
iSCSI
In-
Guest
OS
SMB
FCoE RDM VMFS
Shared
Disk
MSCS with
Shared Disk
Yes Yes1 Yes No
5
2 (pre-5.1 only)
Yes Yes No Yes5 Yes4 Yes2 Yes3
Exchange Single
Copy Cluster
Yes Yes1 Yes No
2
5 (5.1 only)
Yes Yes No Yes5 Yes4 Yes2 Yes3
SQL Clustering Yes Yes1 Yes No
2
5 (5.1 only)
Yes Yes No Yes5 Yes4 Yes2 Yes3
SQL AlwaysOn
Failover Cluster
Instance
Yes Yes1 Yes No
2
5 (5.1 only)
Yes Yes No Yes5 Yes4 Yes2 Yes3
Non
shared
Disk
Network Load
Balance
Yes Yes1 Yes Yes
Same as
OS/app
Yes Yes Yes N/A Yes N/A N/A
Exchange CCR Yes Yes1 Yes Yes
Same as
OS/app
Yes Yes Yes N/A Yes N/A N/A
Exchange DAG Yes Yes1 Yes Yes
Same as
OS/app
Yes Yes Yes N/A Yes N/A N/A
SQL AlwaysOn
Availability
Group
Yes Yes1 Yes Yes
Same as
OS/app
Yes Yes Yes N/A Yes N/A N/A
vMotion with Shared Disk Configurations:
Requires Hardware 11 Compatibility (vSphere 6.0)
Physical Mode Required for vSCSI Controller
Non-Shared Disk Configurations:
No VMware Restrictions
* Use affinity/anti-affinity rules when using vSphere HA
VMware Knowledge Base Article: http://kb.vmware.com/kb/1037959
Support for Microsoft Clustering on vSphere
CONFIDENTIAL 46

47. vSphere HA with Shared Disk Clustering
• Supports up to five-node cluster in vSphere 5.1 and
above
• Host attach (FC) , FCoE* or in-guest (iSCSI)
• Supports RDM only
– RDMs can be vMotioned in vSphere 6.0!!!
– Use DRS affinity/anti-affinity rules to avoid running cluster
virtual machines on the same host
• vSphere HA + failover clustering
– Seamless integration, virtual machines rejoin clustering
session after vSphere HA recovery
– Can shorten time that database is in unprotected state
CONFIDENTIAL 47
Failover clustering supported with vSphere HA since vSphere 4.1
http://kb.vmware.com/kb/1037959
vSphere Cluster 1 – HA-enabled
SQL Server
Databases
Normal Operation
Physical disks do not move.
vSphere Cluster 1 – HA-enabled
SQL Server
Databases
Cluster Failover
DB Failover
Physical disks do not move.
vSphere Cluster 1 – HA-enabled
SQL Server
Databases
Recovery
HA Reboots
Physical disks do not move.

48. vSphere HA with AlwaysOn Availability Groups
• Seamless integration
• Protect against hardware/software failure
• DRS anti-affinity rule avoids running virtual
machines on the same host
• Support multiple secondary and readable
secondary
• Provide local and remote availability
• Full feature compatibility with availability group
• vSphere HA + failover clustering
– Seamless integration, virtual machines rejoin clustering
session after vSphere HA recovery
– Can shorten time that database is in unprotected state
CONFIDENTIAL 48
Witness
Direction of data flow
vSphere Cluster 1 – HA-enabled
SQL Server
Databases
Normal Operation
Full Quorum
vSphere Cluster 1 – HA-enabled
SQL Server
Databases
Cluster Failover
DB Failover
Witness-to-Partner
Quorum
vSphere Cluster 1 – HA-enabled
SQL Server
Databases
HA Recovery
HA Reboots
Full Quorum

49. Resources
• Visit us on the web to learn more on specific apps
– http://www.vmware.com/solutions/business-critical-apps/
– Specific page for each major app
– Includes Best Practices and Design/Sizing information
• Visit our Business Critical Application blog
– http://blogs.vmware.com/apps/
CONFIDENTIAL 49

50. Questions?
CONFIDENTIAL 50

53. Advanced SQL Server on vSphere
Scott Salyer, VMware, Inc
Wanda He, EMC
VAPP5598
#VAPP5598