VMworld 2014: Advanced SQL Server on vSphere Techniques and Best Practices

Advanced SQL Server on vSphere Techniques and Best Practices VAPP2979 Scott Salyer, VMware, Inc Jeff Szastak, VMware, Inc

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 CONFIDENTIAL 3 1 Introductions 2 Storage •  Data Volume and Protocol Considerations •  Designing for Performance 3 Networking •  Jumbo Frames •  Guest Tuning 4 Memory •  Understanding Memory Management •  Best Practices in SQL Server Guests

Agenda / Table of Contents CONFIDENTIAL 4 5 CPU •  Best Practices •  Sizing Considerations 6 Consolidating Multiple Workloads •  Consolidation Options •  Mixing Workload Types 7 SQL Server Availability •  vSphere Features •  Supported SQL Server Clustering Configurations

Storage: Disk Volume and Protocol Considerations CONFIDENTIAL5

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"

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

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

PVSCSI, Anyone? •  The latest and most advanced vSphere SCSI controller drivers •  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

…and what about NFS and In-guest iSCSI? •  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

Storage: Designing for Performance CONFIDENTIAL12

VMFS Design for Storage Performance (not just Capacity) •  The fundamental relationship between consumption and supply has not changed –  Spindle count and RAID configuration still rule –  But host demand is an aggregate of virtual machines •  Factors that affect storage performance include storage protocols, storage configuration, and Virtual Machine File System (VMFS) configuration

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

LUN Size •  In the example, VMware ESXi™ B can generate twice as much I/O as ESXi A •  Improved aggregate throughput of multiple LUNs •  Implications for the array –  Greater number of smaller LUNs increases burst intensity –  Many HBA/LUN pairs could be used simultaneously ESXi A 1 2 … 32 VM a VM b VMFS ESXi B 1 2 … 32 VM c VM d 1 2 … 32

Performance Best Practices •  DataStores –  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 •  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 •  Choose Storage which supports VMware vStorage APIs for Array Integration (VAAI) •  Deploy vSphere Flash Read Cache (vFRC) –  a volatile write-through cache –  caches read requests of virtual machine I/O requests –  enabled on a per-vmdk basis with a cache block size (4KB - 1MB)

Performance Best Practices (continued) •  Follow storage vendor’s best practices when laying out database (also storage multipathing) •  Use multiple vSCSI adapters to evenly distribute target devices and increase parallel access for databases with demanding workloads •  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) –  See “Benefits of EMC VNX for Block Integration with VMware VAAI” http://www.us.emc.com/collateral/hardware/white-papers/h8293-vaai-vnx-wp.pdf •  Network protocol processing for software-initiated iSCSI / NFS operations take place on the host system, requiring CPU resources •  Follow same guidelines as physical –  separate LUNs with different IO characteristics i.e. data, redo / log, temporary, rollback

Performance Best Practices (continued) •  Be conservative – for mission critical production, dedicate LUNs for above disks •  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 •  Storage Multipathing – Set up a minimum of four paths from an ESX Server to a storage array (requires at least two HBA ports) •  Configure maximum queue depth if needed for Fibre Channel HBA cards. See: –  http://kb.vmware.com/kb/1267 –  http://kb.vmware.com/kb/1267

SQL Server Guest Storage Best Practices •  Follow SQL Server storage best practices – http://technet.microsoft.com/en-us/library/cc966534.aspx •  Ensure correct sector alignment in Windows –  Incorrect setting can result in up to 50% performance hit –  Don’t use the “Quick format” option for database/log volumes •  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

Storage – Putting It ALL Together •  Work with storage engineer early in the lifecycle •  Optimize VMFS and avoid lazy zeroing by using eagerzeroedthick disks •  Ensure that blocks are aligned at both the ESXi and Windows levels •  Understand the path to the drives, such as storage protocol and multipathing •  Size for performance, not just capacity (apps often drive performance requirements) •  Understand the I/O requirements of different workloads –  Separate LUNs for files with different I/O characteristics, such as transactional data versus log versus backup –  Separate VMDKs for SQL binary, data, log, and tempdb files •  Use small LUNs for better manageability and performance •  Optimize IP network for iSCSI and NFS

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 http://kb.vmware.com/kb/1007654

SQL Server: Network •  Network •  Default packet size is 4,096 –  If jumbo frames are available for the entire stack, set packet size to 8,192 •  Maximize Data Throughput for Network Applications –  Limit file system cache by OS –  NIC > File & Printer Sharing Microsoft Networks •  Use Minimize Memory or Balance http://blogs.msdn.com/b/johnhicks/archive/2008/03/03/sql-server-checklist.aspx

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>

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) •  For “chatty” VMs on same host, connect to same vSwitch to avoid pNIC traffic •  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 •  Be mindful of converged networks; storage load can affect network and vice versa as they use the same physical hardware •  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 •  Ensure no bottlenecks in the network between the source and destination •  Look out for Packet Loss / Network Latency if a network issue is detected

Memory Understanding Memory Management

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, be sure to wait at least 1 business cycle (vCOPs)

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

Memory ALLOCATED TO a VM Is Determined by…. •  DRS Shares/Limits** •  Total Memory of the Host •  Reservations •  Memory Load of the host

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 •  CPU Hot-Add disables vNUMA •  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)

Memory Best Practices in SQL Server Guests

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

Lock Pages in Memory User Right •  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

Running Multiple Instances on Same VM •  Option 1: Use max server memory –  Create max setting for each instance –  Give each instance memory proportional to expected workload / db size –  Do not exceed total RAM allocated to VM •  Option 2: Use min server memory –  Create min settings for each instance –  Give each instance memory proportional to expected workload / db size –  The sum should be 1-2 GB less than RAM allocated to VM Pro Con Max server memory When a new process or instance starts, memory is available immediately to fulfill the request If instances are not running, the running instances cannot access the available RAM Min server memory Running instances can leverage memory previously used by instances that are no longer running When a new process or instance starts, running instances need to release memory Max Memory = VMMem – ThreadStack – OS Mem – VM Overhead •  ThreadStack = NumOfSQLThreads(ThreadStackSize) •  ThreadStackSize = 1 MB on x86 | 2 MB on x64 hDp://msdn.microsoI.com/en-‐us/library/ms178067.aspx Settings can be modified without having to restart the instances!

How Many VMs Can I Put on a Host? •  As many whose active memory will fit in physical RAM, while leaving some room for memory spikes. Active memory (%ACTV) of VM’s + Memory Overhead – Page sharing of VM’s (DE-Duping) DE-Duping = Transparent Page Sharing

Memory – Putting It ALL Together •  Use ESXi Large Pages •  Avoid host-level swapping –  Utilize ESXi memory management features like TPS and ballooning (don’t disable!) –  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

CPU Sizing Considerations •  Understand existing workload, average and peak •  Properly manage pCPU allocation –  For Tier 1 workload, avoid pCPU overcommitment –  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

Processor – Putting It All Together •  Leverage hardware-assisted virtualization (enabled by default) •  Consider avg. and peak utilization •  Be aware of hyper-threading, a hyper-thread does not provide the full power of a physical core •  Consider future growth of the system, sufficient head room should be reserved •  In high performance environment, consider adding additional hosts when avg. host CPU utilization exceeds 65% •  Consider increasing CPU resource if guest VM CPU utilization is above 65% in average •  Ensure Power Saving Features are “OFF” •  Use vCOPs for consumption & capaticity

Consolidating Multiple Workloads CONFIDENTIAL50

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

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) Yes Yes No Yes5 Yes4 Yes2 Yes3 SQL Clustering Yes Yes1 No No 2 5 (5.1 only) Yes Yes No Yes5 Yes4 Yes2 Yes3 SQL AlwaysOn Failover Cluster Instance Yes Yes1 No 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 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 http://kb.vmware.com/kb/1037959

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 63

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

Fill out a survey Every completed survey is entered into a drawing for a $25 VMware company store gift certificate

VMworld 2014: Advanced SQL Server on vSphere Techniques and Best Practices

More Related Content

What's hot

Viewers also liked

Similar to VMworld 2014: Advanced SQL Server on vSphere Techniques and Best Practices

More from VMworld

Recently uploaded

VMworld 2014: Advanced SQL Server on vSphere Techniques and Best Practices