VMware SQL Server Virtualization Performance Best Practices

Disclaimer
• 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.
CONFIDENTIAL 2

Agenda / Table of Contents
• Introduction – Why Virtualize SQL Server?
• Designing for Performance (Tier-1 Production)
– Data Volume and Protocol Considerations
– Database Workload Types and Characteristics
– Understanding Memory Management
– Memory Best Practices in SQL Server Guests
– Networking Best Practices
– NUMA
• Consolidating Multiple SQL Server Workloads
– Consolidation Options
– Mixing Workload Types
• SQL Server Availability
– vSphere Features
– Supported SQL Server Clustering Configurations
CONFIDENTIAL 4

Introduction
Why virtualize SQL Server?
CONFIDENTIAL5

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 resilliency

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 Databases on VMware SDDC?
7
Licensing
Complete isolation between systems on the same host
• Protects databases and applications against network-based
threats
Security

VMware SDDC Simplifies Common DBA Tasks

Designing for Performance
Tier-1 Production Workloads
CONFIDENTIAL9

Performance Best Practices Summary
• Design for performance in addition to capacity; more disks = faster
• Dedicate DataStores for performance critical workloads
• Avoid Lazy Zeroing; use VAAI array or eagerzeroedthick
• Pre-test your workload
• Use PVSCSI adapters when possible (non-clustered databases)
• Use multiple paths to storage array (minimum 2 HBAs)
• Use Large Memory Pages at the host
• Avoid host-level swapping; don’t disable TPS and ballooning
• Optimize network for IP-based storage protocols
• Use multiple vSCSI adapters (up to 4)
• Avoid CPU and Memory overcommit; alternatively, use reservations
• Use Large Memory Pages in the guest; enable LockPagesInMemory user right
• Place t-logs, tempdb, and data files on separate LUNs

VMFS
Design for Storage Performance (not just Capacity)
• The fundamental relationship between consumption and
supply has not changed
– Spindle count and RAID configuration are still important
– But host demand is an aggregate of virtual machines
• DataStores (work with Storage Engineer early in Design)
– Create dedicated data stores to service BCA database workloads
– svMotion / SDRS to balance workloads across DataStores
– Load Balance your workloads across as many disk spindles as
possible
– Follow storage vendor’s best practices when laying out database
– Storage Multipathing – Set up a minimum of four paths from an
ESX Server to a storage array (requires at least two HBA ports)
• Factors that affect storage performance include storage
protocols, storage configuration, and Virtual Machine File
System (VMFS) configuration

Design for Storage Performance (cont.)
• Ensure storage adapter cards are installed in slots with enough bandwidth to support their
expected throughput
• Ensure appropriate read/write controller cache is enabled
• Pick the right multipathing policy based on vendor storage array design
• Configure maximum queue depth if needed for Fibre Channel HBA cards. See:
– http://kb.vmware.com/kb/1267
– http://kb.vmware.com/kb/1267

VMFS or RDM?
• Generally similar performance http://www.vmware.com/files/pdf/performance_char_vmfs_rdm.pdf
• vSphere 5.5 supports up to 62TB VMDK files
• Disk size no longer a limitation of VMFS
VMFS RDM
Better storage consolidation – multiple virtual disks/virtual machines per
VMFS LUN. But still can assign one virtual machine per LUN
Enforces 1:1 mapping between virtual machine and
LUN
Consolidating virtual machines in LUN – less likely to reach vSphere
LUN Limit of 256
More likely to hit vSphere LUN limit of 256
Manage performance – combined IOPS of all virtual machines in LUN <
IOPS rating of LUN
Not impacted by IOPS of other virtual machines
• When to use raw device mapping (RDM)
– Required for shared-disk failover clustering
– Required by storage vendor for SAN management tools such as backup and snapshots
• Otherwise use VMFS

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 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)

Eagerzeroed Thick in the GUI
• When using VMFS for SQL Server data, create VMDK files as eagerzeroed thick or uncheck
Windows “Quick Format” option
vSphere 4
vSphere 5

OLTP
 Large amount of small queries
 Sustained CPU utilization during working hours
 Sensitive to peak contentions (slow downs affects SLA)
 Generally Write intensive
 May generate many chatty network round trips
 Typically runs during off-peak hours, low CPU utilization during
normal working hours
 Can withstand peak contention, but sustain activity is key
Batch / ETL
DSS
 Small amount of large queries
 CPU, memory, disk IO intensive
 Peaks during month end, quarter end, year end
 Can benefit from inter-query parallelism with large number of threads
Database Workloads Types

SQL Server I/O Characteristics
• Understanding the I/O characteristics of common SQL Server operations and scenarios can
help determine how to configure storage
• Some of the more common scenarios below
• Monitor I/O to determine specifics of each scenario
Operation Random/Sequential Read/Write Size Range
OLTP – Log Sequential Write Up to 64K
OLTP – Data Random Read/Write 8K
Bulk Insert Sequential Write Any multiple of 8K up to 256K
Read Ahead – DSS and Index Scans Sequential Read Any multiple of 8KB up to 512K
Backup Sequential Read 1MB

Storage – Test Before Deployment
• Simulate SQL Server disk I/O patterns using a generic tool, such as the native SQLIOSim or
Iometer
• Test to make sure requirements, such as throughput and latency, have been met
• Example SQL I/O patterns to tests
R/W% Type Block Threads/ Queue Simulates
80/20 Random 8K # cores/files Typical OLTP data files
0/100 Sequential 60K 1/32 Transaction log
100/0 Sequential 512K 1/16 Table scans
0/100 Sequential 256K 1/16 Bulk load
100/0 Random 32K # cores/1 SSAS workload
100/0 Sequential 1MB 1/32 Backup
0/100 Random 64K-256K # cores/files Checkpoints

Storage – Best Practices Summary
• Size for performance, not just capacity (apps often drive performance requirements)
• Format database VMDK files as Eager Zeroed Thick* for demanding workload database
– * Required ONLY if the storage array is not VAAI-compliant. See VMware KB #1021976
(http://kb.vmware.com/kb/1021976)
• Ensure that blocks are aligned at both the ESXi and Windows levels
• Understand the path to the drives, such as storage protocol and multipathing
• Understand the I/O requirements of the workload and TEST
• Use small LUNs for better manageability and performance
• Optimize IP network for iSCSI and NFS
– NOTE: Network protocol processing for software-initiated iSCSI / NFS operations take place on the
host system, requiring CPU resources
• Use multiple vSCSI adapters to evenly distribute target devices and increase parallel access for
databases with demanding workloads

Performance Best Practices Summary
• Design for performance in addition to capacity; more disks = faster
• Dedicate DataStores for performance critical workloads
• Avoid Lazy Zeroing; use VAAI array or eagerzeroedthick
• Pre-test your workload
• Use multiple paths to storage array (minimum 2 HBAs)
• Use Large Memory Pages at the host
• Avoid host-level swapping; don’t disable TPS and ballooning
• Optimize network for IP-based storage protocols
• Design with NUMA in mind; use Virtual NUMA to extend awareness to guest
• Use multiple vSCSI adapters (up to 4)
• Avoid CPU and Memory overcommit; alternatively, use reservations
• Use Large Memory Pages in the guest; enable LockPagesInMemory user right
• Place t-logs, tempdb, and data files on separate LUNs

Large Pages
• Use ESXi Large Pages (2MB)
– Improves performance by significantly reducing TLB misses (applications with large active memory
working sets)
– Does not share large pages unless memory pressure (KB 1021095 and 1021896)
– Slightly reduces the per-virtual-machine memory space overhead
• For systems with Hardware-assisted Virtualization
– Recommend use guest-level large memory pages
– ESXi will use large pages to back the GOS memory pages even if the GOS does not make use of large
memory pages(full benefit of huge pages is when GOS use them as well as ESXi does)

“Large Pages Do Not Normally SWAP”
http://kb.vmware.com/kb/1021095
In the cases where host memory is overcommitted, ESX may have
to swap out pages. Since ESX will not swap out large pages,
during host swapping, a large page will be broken into small
pages. ESX tries to share those small pages using the pre-
generated hashes before they are swapped out. The motivation of
doing this is that the overhead of breaking a shared page is
much smaller than the overhead of swapping in a page if the
page is accessed again in the future.

Swapping is Bad!
• Swapping happens when:
– The host is trying to service more memory than it has physically AND
– ESXi memory optimization features (TPS and Ballooning) are insufficient to provide relief
• Swapping Occurs in Two Places
– Guest VM Swapping
– ESXi Host Swapping
• Swapping can slow down I/O performance of disks for other VM’s
• Two ways to keep swapping from affecting your workload:
– At the VM: Set memory reservation = allocated memory (avoid ballooning/swapping)
• Use active memory counter with caution and always confirmed usage by checking memory counter in Perfmon
– At the Host: Do not overcommit memory until vCenter reports that steady state usage is < the amount
of RAM on the server

ESXi Memory Features that Help Avoid Swapping
• Transparent Page Sharing
– Optimizes use of memory on the host by “sharing” memory pages
that are identical between VMs
– More effective with similar VMs (OS, Application, configuration)
– Very low overhead
• Ballooning
– Allows the ESXi host to “borrow” memory from one VM to satisfy
requests from other VMs on that host
– The host exerts artificial memory pressure to the VM via the
“balloon driver” and returns to the pool usable by other VMs
– Ballooning is the host’s last option before being forced to swap
– Ballooning is only effective if VMs have “idle” memory
• DON’T TURN THESE OFF

Memory Reservations
• Allows you to guarantee a certain share of the physical
memory for an individual VM
• The VM is only allowed to power on if the CPU and
memory reservation is available (strict admission)
• The amount of memory can be guaranteed even under
heavy loads.
• In many cases, the configured size and reservation size
could be the same

Reservations and vswp
• Setting a reservation creates a 0.00 K

Network Best Practices
• Allocate separate NICs for vMotion, FT logging traffic, and ESXi console access management
– Alternatively use VLAN-trunking support to separate production users, management, VM network, and
iSCSI storage traffic
• vSphere 5.0 supports the use of more than 1 NIC for vMotion allowing more simultaneous
vMotions; added specifically for memory intensive applications like Databases
• Use NIC load-based teaming (route based on physical NIC load) for availability, load balancing,
and improved vMotion speeds
• Have minimum 4 NICs per host to ensure performance and redundancy of network
• Recommend the use of NICs that support:
– Checksum offload , TCP segmentation offload (TSO)
– Jumbo frames (JF), Large receive offload (LRO)
– Ability to handle high-memory DMA (i.e. 64-bit DMA addresses)
– Ability to handle multiple Scatter Gather elements per Tx frame
– NICs should support offload of encapsulated packets (with VXLAN)

Network Best Practices (continued)
• Separate SQL workloads with chatty network traffic (Microsoft Always On – Are you there) from
the one with chunky access into different physical NICs
• Use Distributed Virtual Switches for cross-ESX network convenience
• Optimize IP-based storage (iSCSI and NFS)
– Enable Jumbo Frames
– Use dedicated VLAN for ESXi host's vmknic & iSCSI/NFS server to minimize network interference from
other packet sources
– Exclude iSCSI NICs from Windows Failover Cluster use
– Be mindful of converged networks; storage load can affect network and vice versa as they use the
same physical hardware; ensure no bottlenecks in the network between the source and destination
• Use VMXNET3 Paravirtualized adapter drivers to increase performance
– Reduces overhead versus vlance or E1000 emulation
– Must have VMware Tools to enable VMXNET3
• Tune Guest OS network buffers, maximum ports

Jumbo Frames
• Use Jumbo Frames – confirm there is no MTU mismatch
• To configure, see iSCSI and Jumbo Frames configuration on ESX 3.x and ESX 4.x

AlwaysOn Availability Group Cluster Settings
• Depending on YOUR network, tuning may be necessary – work with Network Team and
Microsoft to determine appropriate settings
Cluster Heartbeat
Parameters
Default
Value
CrossSubnetDelay 1000 ms
CrossSubnetThreshold 5hb
SameSubnetDelay 1000 ms
SameSubnetThreshold 5 hb
View: cluster /cluster:<clustername> /prop
Modify: cluster /cluster:clustername> /prop <prop_name> = <value>

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

Virtual NUMA in vSphere 5
• 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
• SQL Server
– Automatically detects NUMA architecture
– SQL Server process and memory allocation optimized for
NUMA architecture

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)
• Hyperthreading
– Initial conservative sizing: set vCPUs to # of cores
– HT benefit around 20-25%, < for CPU intensive batch jobs (based on OLTP workload tests )
– Increase vCPUs to get HT benefit, but consider “numa.vcpu.preferHT” option – individual case basis
• # of virtual sockets and # of cores / virtual socket
– Recommendation , keep default 1 core / socket
• Align VMs with physical NUMA boundaries
• ESXTOP to monitor NUMA performance at vSphere
• If vMotioning, move between hosts with the same NUMA architecture to avoid performance hit
(until reboot)

PVSCSI Adapters
• The latest and most advanced vSphere SCSI controller drivers; recommended for workloads
with a high performance requirement
• Larger queue depth per-device (256, actual 254) and per-adapter(1024)
– Default values are 64 and 254
• Less CPU overhead
• Requires VMware Tools
– Drivers not native to Windows
– Cannot be used for OS partition without some work-around
• Increase queue depth in Windows Guest OS by increase request ring to 32
– HKLMSYSTEMCCSservicespvscsiParametersDeviceDriverParameter
"RequestRingPages=32,MaxQueueDepth=254”
– ESX 5.0 U3 and above only
• Not currently supported for ANY type of Windows Clustering configuration

NFS, In-guest iSCSI, and vSCSI Adapters
• NFS
– Supported for SQL Server (must meet data write ordering requirements and guarantee write-through)
– Not supported by VMware for Windows Clustering
• In-guest iSCSI
– Supported for Standalone and Clustered
• No VMware-mandated considerations
– Facilitates easy storage zoning and access masking
– Useful for minimizing number of LUNs zoned to an ESXi host
– Offloads storage processing resources away from ESXi hosts
– Should use dedicated network and NIC
• vSCSI Adapters (configured in VM properties)
– Use multiple vSCSI adapters to evenly distribute target devices and increase parallel access for

Guest Memory – Best Practices Summary
• Avoid overcommitment of memory at the host level (HostMem >= Sum of VMMem – overhead)
– If overcommitment is unavoidable, use reservations to protect important VMs
• To avoid NUMA remote memory access, size VM memory equal to or less than the memory
per NUMA node if possible
– Utilize ESXi virtual NUMA features (especially for wide VMs)
• Use Large Pages in the guest – start SQL Server with trace flag -T834
• Enable Lock Pages in Memory right for SQL Server service account
• Use Max Server Memory and Min Server Memory when running multiple instances of SQL
Server in the same VM
• Disable unnecessary processes within Windows

Large Pages in SQL Server Configuration Manager (Guest)
• Use Large Pages in the guest – start SQL Server with trace flag -T834

Lock Pages in Memory User Right (Guest)
• May keep SQL Server more responsive
when paging occurs
• ON by default in 32/64 bit Standard
Edition and higher if rights are granted
• The SQL Server Service Account
(sqlservr.exe) must have “Lock pages in
memory” rights
http://msdn.microsoft.com/en-us/library/ms178067.aspx

CPU Sizing Considerations
• Understand existing workload, average and peak; consider future growt
• Properly manage pCPU allocation
– For Tier 1 workload, avoid pCPU overcommitment or use reservations
– For lower-tiered databases workload
• Reasonable overcommitment can increase aggregate throughput and maximize license savings – consolidation
ratio varies depending on workloads
• Leverage vMotion and DRS for resource load balancing
– Monitor to optimize
• Host level – %RDY, %MLMTD, and %CSTP
• Virtual machine level – processor queue length
• Keep NUMA node size in mind
– For smaller virtual machine, try to stay inside a NUMA node if possible
– For wide virtual machine – vSphere 5.x
• Align vCPUs to physical NUMA boundaries
• Enable vNUMA on vSphere host to allow SQL Server NUMA optimization

CPU Sizing Considerations (cont.)
• Leverage hardware-assisted virtualization (enabled by default)
• Be aware of hyper-threading, a hyper-thread does not provide the full power of a physical core
• In high performance environment, consider adding additional hosts when avg. host CPU
utilization exceeds 65%
• Ensure Power Saving Features are “OFF”
• Use vCOPs for consumption & capacity metrics

SQL Server Guest Storage Best Practices
• Follow SQL Server storage best practices – http://technet.microsoft.com/en-us/library/cc966534.aspx
• Pre-allocate data files to avoid autogrow during peak time
– If using auto-growth, use MB and not % increments
• Use multiple data files for data and tempdb – start with 1 file per CPU core
– Multiple TempDB files can co-exist on the same volume – Not encouraged
• Database file placement priority – fastest to slowest drive
– Transaction Log Files > TempDB Data Files > Data Files
• Place data and log files on separate LUNs
• Perform routine maintenance with index rebuild/reorg, dbcc checkdb
• Number of Data Files Should Be <= Number of Processor Cores
• Use multiple vSCSI adapters to evenly distribute target devices and increase parallel access for

Block Alignment
• Configure storage presented to vSphere hosts using
vCenter to ensure VMFS block alignment
• Even though Windows is supposed to automatically align
as of Windows 2008, Microsoft recommends double
checking
– 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)
• Whatever the operating system, confirm that new
partitions are properly aligned
Unaligned partitions result in additional I/O
Aligned partitions reduce I/O
stripe unit size value should be an integer

Consolidating Multiple
Workloads
CONFIDENTIAL45

Consolidation Options
• Scale-up approach
– Multiple databases or SQL instances per
virtual machine
– Fewer virtual machines
– Poor workload management
– Potential reduction in SQL licensing cost
• Scale-out approach
– Single database per VM
– Potential increase in mgmt. overhead
– Better isolation/performance
– Easier security and change mgmt.
– DRS more effective with smaller VMs
– Faster migration (vMotion)
46

OLTP vs. Batch Workloads
• What this says:
– Average 15% Utilization
– Moderate sustained activity (around 28% during working
hours 8am-6pm)
– Minimum activities during non 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%)

OLTP vs. Batch Workloads
• What This Means
– Better Server Utilization
– Improved Consolidation Ratios
– Less Equipment To Patch, Service, Etc
– Saves Money/Less Licensing
OLTP/Batch Combined Workload

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
– Additional virtual machines can be added to handle peak period during month-end, quarter-end, and
year-end, if scale out is a possibility
– CPU and memory hot add can be used to handle workload peak
– Reduce virtual machine density, or add more hosts to the cluster
• Use DRS as your insurance policy, but don’t rely on it for resource planning

Business-Level Approach
• What are you trying to protect?
– i.e. What does the business care about protecting?
• What are your RTO/RPO requirements?
• What is your Service Level Agreement (SLA)?
• How will you test and verify your solution?

vSphere 5 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!

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 No No
2
5 (5.1 only)
Yes Yes No Yes5 Yes4 Yes2 Yes3
Exchange Single
Copy Cluster
Yes Yes1 No No
2
5 (5.1 only)
SQL Clustering Yes Yes1 No No
2
5 (5.1 only)
SQL AlwaysOn
Failover Cluster
Instance
Yes Yes1 No No
2
5 (5.1 only)
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
Exchange DAG Yes Yes1 Yes Yes
Same as
OS/app
SQL AlwaysOn
Availability
Group
Yes Yes1 Yes Yes
Same as
OS/app
Shared Disk Configurations: Supported on
vSphere with additional considerations for storage
protocols and disk configs
Non-Shared Disk Configurations: Supported on
vSphere just like on physical
* Use affinity/anti-affinity rules when using vSphere HA
** RDMs required in “Cluster-across-Box” (CAB) configurations, VMFS required in “Cluster-in-Box” (CIB) configurations
VMware Knowledge Base Article: http://kb.vmware.com/kb/1037959
VMware Support for Microsoft Clustering on vSphere

Shared Disk Clustering (Failover Clustering and AlwaysOn FCI)
• Provides application high-availability through a shared-disk architecture
• One copy of the data, rely on storage technology to provide data redundancy
• Automatic failover for any application or user
• Suffers from restrictions in storage and VMware configuration

vSphere HA with Shared Disk Clustering
• Supports up to five-node cluster in vSphere 5.1 and above
• Failover cluster nodes can be physical or virtual or any
combination of the two
• Host attach (FC) , FCoE* or in-guest (iSCSI)
• Supports RDM only
• vSphere HA + failover clustering
– Seamless integration, virtual machines rejoin clustering session
after vSphere HA recovery
– Can shorten time that database is in unprotected state
– Use DRS affinity/anti-affinity rules to avoid running cluster
virtual machines on the same host
Failover clustering supported with vSphere HA as of vSphere 4.1

Non-Shared Disk Clustering (Always On Availability Groups)
• Database-level replication over IP; no shared storage requirement
• Same advantages as failover clustering (service availability, patching, etc.)
• Readable secondary
• Automatic or manual failover through WSFC policies

vSphere HA with AlwaysOn Availability Groups
• Seamless integration
• Protect against hardware/software failure
• Support multiple secondary and readable secondary
• Provide local and remote availability
• Full feature compatibility with availability group
• VMware HA shortens time that database is in unprotected
state
• DRS anti-affinity rule avoids running virtual machines on
the same host
EMC Study – SQL Server AlwaysOn running vSphere 5 and EMC FAST VP
http://www.emc.com/collateral/hardware/white-papers/h10507-mission-critical-sql-server-2012.pdf

WSFC – Cluster Validation Wizard
• Use this to validate support for your configuration
– Required by Microsoft Support for condition of support for YOUR configuration
• Run this before installing AAG(AlwayOn Availabilty Group), and every time you make changes
– Save resulting html reports for reference
• If running non-symmetrical storage, possible hotfixes required
– http://msdn.microsoft.com/en-us/library/ff878487(SQL.110).aspx#SystemReqsForAOAG
58

Patching Non-clustered Databases
• Benefits
– No need to deploy an MS cluster simply for patching /
upgrading the OS and database
– Ability to test in a controlled manner (multiple times if
needed)
– Minimal impact to production site
until OS patching completed
and tested
– Patching of secondary VM
can occur during regular
business hours
• Requires you to layout VMDKs correctly to support this
scenario

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/

New RDBMS books from VMware Press
61
vmwarepress.com
http://www.pearsonitcertification.com/store/virtu
alizing-oracle-databases-on-vsphere-
9780133570182
http://www.pearsonitcertification.com/store/virtuali
zing-sql-server-with-vmware-doing-it-right-
9780321927750

VMware SQL Server Virtualization Performance Best Practices

VMware SQL Server Virtualization Performance Best Practices

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (19)

Semelhante a VMware SQL Server Virtualization Performance Best Practices

Semelhante a VMware SQL Server Virtualization Performance Best Practices (20)

Mais de VMworld

Mais de VMworld (20)

Último

Último (20)

VMware SQL Server Virtualization Performance Best Practices