Deploy Highly Available SQL Server for

Virtualization & the Cloud

SQL Saturday #517 - Philadelphia
June 4, 2016

Allan Hirt
Microsoft High Availability MVP
Managing Partner, SQLHA LLC
Twitter: @SQLHA
E-mail: allan@sqlha.com
Web/blog: http://www.sqlha.com
Virtualization

• Ability to run multiple servers (virtual machines, or VMs) under a single host
(hypervisor)
 Not dissimilar to multiple SQL Server instances on a server or WSFC
 VMware has been around since the late 90s, first server product 2002
• VM is a software defined representation of a physical server
 All VMs share the underlying resources of the hypervisor
 Most, if not all, components of a virtualized server environment are software defined
• At some point there is always physical underneath – whether virtualized or
using the public cloud
Promise vs. Reality of Virtualization
Promise
Availability/Reliability Physical can be expensive, hard to
implement
Agility Workloads are portable (better
perf/availability), “run anywhere”
Deployment Reduces time to implement, siloed
deployment tools go away
Utilization Better consolidation, handles sprawl, Now have noisy neighbors,
better overall usage
Reality
Can be more complex, backup
story now much more fuzzy
It’s not as simple as moving
things around
Only really works if IT
embraces things like
templates, need proper
monitoring
overcommit of resources, still
may need dedicated hosts
Hyper-V vs. VMware – High Level Comparison
• Parity on both sizing
and features Parameter Hyper-V vSphere 5.1 vSphere 6.0
• Each “one ups” or (2012 R2)
catches up to the Logical Processors 320 160 480
Host
other in releases Physical memory 4TB 2TB 6TB

• Cost is a factor Virtual CPUs/host 2,048 2,048 4,096

Virtual CPUs/VM 64 64 128
 Licensing Virtual Memory/VM 1TB 1TB 4TB
 Editions/Features Machines
VMs running/host 1,024 512 1,024
• Administration is NUMA supported Yes Yes Yes
biggest difference Cluster Nodes/Hosts 64 32 64
 vCenter (VMware)
Total VMs/cluster 8,000 4,000 8,000
vs. System Center
suite (Microsoft)
Virtualization and SQL Server Availability – Part 1

• In-guest or hypervisor … or something else?

• Anatomy of a real world availability solution with virtualization
 Many solutions leverage both SQL Server and hypervisor techniques to achieve the
right end result
 Use the right feature for the job, requirements; not all or nothing
 Need to understand requirements, RTOs, RPOs, differences of in-guest vs. hypervisor
• Control/political issues?
• Part of the challenge: advanced SQL Server features often dictate a more
complex VM configuration
Virtualization and SQL Server Availability – Part 2

• AGs a more natural fit under virtualization – standalone instance scenario

 No shared storage
• FCIs
 Understand why you want to use them – availability? Patching?
 Shared storage is the challenge
 Storage redundancy matters esp. if using VHDX/VMDKs
• Networking
 All about bandwidth and proper redundancy
• Anti-affinity for the nodes (AG or FCI) if used for availability
• Bottom line for all aspects: prevent single point(s) of failure
Hyper-V Availability Features

• Basic high availability

 Cluster the hypervisor hosts and created clustered VMs (not in-guest clustering)
 Like an FCI, stop and start on another WSFC node; outage to anything connected
• Live Migration
 Rehost the VM on another hypervisor host with minimal impact
• Hyper-V Replica
 Creates a replica of the VM elsewhere
• Shared VHDX for guest clusters
• Lots of things at the WSFC level
 Example: Site Awareness in Windows Server 2016
 Many things around networking/storage
VMware Availability Features

• vSphere HA
 Cluster the hypervisor hosts and created clustered VMs (not in-guest clustering)
 Like an FCI, stop and start on another node; outage to anything connected
• vSphere Fault Tolerance (FT)
 Can work with HA
 Similar to Hyper-V Replica
• vMotion
 Similar to Live Migration
• Distributed Resource Scheduler (DRS)
 Load balancing (essentially), vMotion with no interrupting
 Have to evaluate with some SQL Server workloads – may not be a fit
• Site Recovery Manager
 Great for D/R
The Public Cloud

• Current big players: Amazon (EC2 and RDS) and Azure (IaaS and SQL
Database)
• VMs (EC2/IaaS) vs. database (RDS/SQL Database)
• Build or “buy”?
 Their Windows image + your build of SQL Server?
 Their complete image (and maybe you customize)?
 Total build job by you?
• Licensing
 Bring or rent?
• Amazon https://aws.amazon.com/windows/resources/licensing/
• Azure https://azure.microsoft.com/en-us/pricing/licensing-faq/
Networking for Public Cloud-based VMs

• Private vs. public IP addresses

 Public (Azure)/Elastic IP Address (Amazon) – things that would
need to be exposed (i.e. AG listener)
 May need to manage VM itself if cannot get to another way
• Use static IP addresses, esp. for private
 Set at VM level, not in VM
• Same for DNS in Azure
• Leave DHCP set in IaaS VM
• AG listener requires an internal load balancer in Azure
• Have to give static IP at VM level for clustered IPs in Amazon
Storage in the Public Cloud

• OS vs. data/log disks

• Know your IOPS
 Azure – must be DS or GS series to use Premium SSD storage
• Size of VM may depend on region availability, so certain options may not be
available
• Backup storage
 One of the best uses of Azure
 IOPS not really the main concern
 Can use it today
Public Cloud and Location
• Azure
 Regions
 Availability sets – somewhat like app tiers; per region
 Fault domain
• Physical boundary – power source & network switch (not nec. same
rack)
• HA IaaS VMs should be in different fault domains if in same data
center
• Classic = 2, ARM = 3
 Update domain
• Logical, relates to updating/patching and how reboots are handled
• Amazon AWS
 Regions
 Availability zones within regions (similar to fault domain)
Public Cloud and SQL Server Availability

• FCIs
 Not a great fit
 Can work (SMB, SIOS Datakeeper)
 Networking slightly different than an on premise solution
• AGs
 Good fit, but some of the same networking weirdness as FCI for WSFC
• DBM
 Good fit but deprecated
• Log shipping
 Works great
Hybrid Solutions

• Two scenarios
 On premise physical or virtual + stretch to the public cloud
 Cloud to cloud (i.e. Azure  AWS)
• Networking will make or break you
 Requires special network configuration
 If have the budget, consider ExpressRoute (Azure) or Direct Connect (Amazon)
• Don’t forget about authentication (i.e. AD)
Don’t Forget Performance

• Performance will cost you – there’s no free lunch

• Dedicated vs. shared hosts
 Especially true with virtualization
 Also impacts cost (potentially positively, but could be negative)
• Power settings (hardware/BIOS/UEFI, hypervisor)
 Same as Windows now … don’t want throttling for no reason
• Networking is the future
 Invest in high bandwidth networking for traditional networking and storage
 Should be using 10Gb or higher now
 RDMA/InfiniBand is awesome if you can afford it
Selected Links

• Supportability for virtualized configurations

 MS support policy for virtualized SQL Server implementations (all hypervisors)
https://support.microsoft.com/en-us/kb/956893
 VMware supported cluster configurations
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId
=1037959
• Configuring the Azure ILB for the AG listener
 Classic https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-sql-server-
configure-ilb-alwayson-availability-group-listener/
 ARM https://blogs.msdn.microsoft.com/brian_farnhill/2016/03/03/configuring-sql-server-alwayson-
availability-groups-in-azure-rm-virtual-machines
• VMware SQL Server HA Whitepaper http://blogs.vmware.com/apps/2016/05/updated-
microsoft-sql-server-on-vmware-vsphere-availability-and-recovery-options.html
• EC2 dedicated hosts https://aws.amazon.com/ec2/dedicated-hosts/