How to deploy SQL Server on an Microsoft Azure virtual machines

SQL SERVER IN MICROSOFT AZURE
VIRTUAL MACHINES – THE IMPORTANT
DETAILS
SCOTT KLEIN
SENIOR TECHNICAL EVANGELIST
MICROSOFT
THOMAS LAROCK
HEAD GEEK
SOLARWINDS

WHY ARE YOU HERE?
» You want to know more about Azure
» You have, or will have, SQL Server running on an Azure VM
» You want to know the important details regarding SQL Server in an Azure VM
© 2015 SOLARWINDS WORLDWIDE, LLC. ALL RIGHTS RESERVED. 2

A LITTLE ABOUT SCOTT…
Scott is a Senior Technical Evangelist for Microsoft
with over 20 years experience as a developer and
architect.
He is a frequent speaker at events around the world.
You can either find him on a plane in the clouds or
on the ground speaking about the Cloud.
scottkl@microsoft.com

A LITTLE ABOUT ME…
Thomas has over 15 years experience in roles
including programmer, developer, analyst, and DBA.
He is a frequent speaker, published author, and avid
blogger on data related technologies.
He enjoys working with data, probably too much to
be healthy, really.

A LITTLE ABOUT SOLARWINDS…
» Network Management
» System Management
» IT Security
» Database Management
» solarwinds.com/products
#Datachat

AGENDA
» Azure Blob Storage
» VM instance size and limits
» Types of Disks
» Disk Performance
» Virtual machine disk cache
» Best Practices
» Troubleshooting
» Disaster Recovery and High Availability

MICROSOFT AZURE BLOB STORAGE
» Two types of durable storage:
 Premium – SSDs -> high-performance, low-latency
 Standard – HDDs
» Run on the new flat network topology
» Disable geo-replication
http://tinyurl.com/azure-storage-scalability
Total Capacity Total Request Rate Total Bandwidth
(Geo-redundant)
Total Bandwidth
(Locally
Redundant)
500 TB 20,000 / sec 10 gb/sec Ingress
20 gb/sec Egress
20 gb/sec Ingress
30 gb/sec Egress

VIRTUAL MACHINE SIZE
» Basic Tier – Up to 8 cores, 14 GB, 240 GB Disk
 Economical option for dev workloads, test servers, apps that
don’t require load balancing or auto-scaling
» Standard Tier – Up to 16 Cores, 112 GB, 382 GB Disk
 Offer the most flexibility
» D Series - Up to 16 Cores, 112 GB, 800 GB Disk
 60% faster CPUs, more memory, and local SSD
» G Series – Up to 32 Cores, 448 GB, 6,500 GB Disk
 Extraordinary performance for demanding applications

DISKS
» OS Disk
 Size: (Gallery image: 127GB)
 Default caching is Read/Write
» Scratch Disk
 Used to store temporary data – data is NOT persisted on Microsoft
Azure Storage (may be wiped clean on VM reboot)
 Can store tempdb and/or BFE on D when using D-series or higher
» Data Disk(s)
 Data disk stored as VHD files inside a single page
 Persistent

DATA DISKS
» Number of disks: Add max number allowed by VM size.
» Caching Policy: None (default). Enable read with Premium storage.
» NTFS allocation: 64KB
» Disk Striping:
 Win8/Server2012, use Storage Spaces. Set stripe size to 64KB for OLTP and
256 KB for DW to avoid performance impact.
 Windows 2008R2 or earlier: use OS striped volumes.
» Data and Log Placement:
 If not an intensive workload, configure one storage pool
 Otherwise, place data and log files on separate disks or storage pools

DISK I/O PERFORMANCE PREDICTABILITY
» Azure Infrastructure Services is a shared, multi-tenant
service
» Where and when you provision your virtual machines
matters
» Maintenance operations have an affect
» Cost vs. Control
» Azure disks vs. local attached disks

VIRTUAL MACHINE DISK CACHE
 Two tier cache
 Most recently accessed data stored in RAM of the physical host
 This cache space is shared by virtual machines on the host.
 Less recently accessed data stored on the local hard disks of the
physical host
 There is a cache space reserved to each virtual machine OS
Disk and Data Disk based on the virtual machine size

VIRTUAL MACHINE DISK CACHE
» Purpose of Microsoft Azure VM disk cache
 Reduce transactions (hence costs) against Azure Storage
 Reduce disk IO latency when IO rate is low
 Improve boot time
» Support Cache Modes
Disk type Read Only Read Write None
OS Disk Supported Default Not Supported
Data Disks Supported Supported Default

SQL Best Practices

PLACEMENT OPTIONS FOR DATA FILES
Place database files across multiple data disks
Create a single volume on top of multiple data disks
Create multiple striped volumes, each with one or more data
disks based on specific I/O performance requirements

SYSTEM DATABASES
» Place on Data Disk
 Adjust the XEvent & Trace file paths, SQL Error log path, default
backup path, default database location.
» Three Reasons Why:
 Performance Variance – More IOPS from the OS disk or a data
disk. Performance of D drive is not predictable due to varying size.
 Configuration upon VM downtime – SQL Server service and file
placement
 Performance Bottleneck – Heavy use of D can introduce IOPS
constraints.

MICROSOFT AZURE VM SQL BEST PRACTICES
» Place user database files (data & log) on data disks; do
not change the default cache setting for data disk
» If the OS disk has to be used:
 Disable write cache (ReadOnly)
 Limit the DB size to 20 GB
» Avoid OS disk striping
 Use SQL striping instead – distribute data files evenly across all
the data disks
» Add more data disks when I/O bound
 Stop adding more disks if no longer gaining IOPs© 2015 SOLARWINDS WORLDWIDE, LLC. ALL RIGHTS RESERVED. 17

TRADITIONAL SQL BEST PRACTICES
» Data page compression recommended for I/O bound
workloads
 Reduce IO
 CPU usage can increase through
» Enable instant file initialization
 Grant (Perform volume maintenance tasks) to SQL Server
 This helps restore and autogrow performance
» Don’t use autogrow, pre-allocate instead
» Disable autoshrink

DISK WARM-UP
» Warm up = “Priming the pump”
» Warm-up affect can result in reduced rate of throughput and
bandwidth
» Warm up will increase costs
» Warm up your disks before measuring performance
 After initializing the file by writing some bit pattern sequentially using
SQLIO for example, run any random IO workload with a high
outstanding I/O (to drive High IOPs) to warm-up the drive. (1 hour
should be sufficient)

APP DESIGN/DEPLOYMENT CONSIDERATIONS
» Moving to the cloud doesn’t solve app design issues
 Poor designs can (and will) get magnified!
» Performance baselining
 Bare metal, Hyper-V, third party hosting
 Hardware (CPU, memory, SSD?)
Understand the constraints of your workload!

PERFORMANCE MONITORING
» Define and monitor key SQL Server performance KPIs
 Maximum value for Process(SQLServ)% Processor Time
 Average value for Process(SQLServ)% Processor Time
 Maximum value for Processor(_Total)% Processor Time
 Average value for Processor(_Total)% Processor Time
 Maximum value for SQLServer:SQL StatisticsBatch Requests/sec
 Average value for SQLServer:SQL StatisticsBatch Requests/sec

KEY PERFORMANCE COUNTERS
Logical disk counter Typical storage term
Suggested actions in
Microsoft Azure virtual machine environment
Disk reads / second
Disk writes / second
IOPS Measure the number of I/O’s per second.
Consider adding more data disks in line with your IOPS
requirements.
Average disk sec / read
Average disk sec / write
Latency Measure disk latency.
Note: Numbers might vary; look at averages over time.
Average disk bytes / read
Average disk bytes / write
Block size Measure the size of I/O’s being issued.
Note: Larger I/O’s tend to have higher latency, such as those
associated with BACKUP/RESTORE.
Average / current disk
queue length
Outstanding or waiting
IOPS
Provides insight into the applications I/O pattern.
Disk read bytes/sec
Disk write bytes/sec
Throughput or aggregate
throughput
Measure of total disk throughput.
Note: Ideally, larger block scans should be able to heavily utilize
connection bandwidth (for example, your throughput can be higher
with a smaller number of larger IOPS).
Monitor along with information from sys.dm_io_virtual_file_stats© 2015 SOLARWINDS WORLDWIDE, LLC. ALL RIGHTS RESERVED. 22

VM DASHBOARD

• Monitor tab for
storage account
• Enabled under the
configure tab
• VM read and write
to their VHDs using
GetBlob and
PutPage
commands
respectively
VM DASHBOARD

TROUBLESHOOTING - STORAGE ANALYTICS
LOGGING
» Enable monitoring of the blob service
 Minimal: only the aggregate value is available for each metric.
Recommended for ongoing monitoring
 Verbose: each metric can be filtered by the specific API of interest.
Recommended for troubleshooting and detailed analysis
» Aggregated data is placed inside the storage account
inside a hidden container called $logs

Disaster Recovery and
High Availability

THE NEED FOR DISASTER-RECOVERY
 An event can cause on-prem SQL Server to become
unavailable
• Temporarily (e.g. gateway failure)
• Permanently (e.g. flooding)
 A disaster recovery site is expensive
• Site rent + maintenance
• Hardware
• Operations

USING AZURE FOR DISASTER RECOVERY

redmond.corp.microsoft.com
uswest.internal.cloudapp.net
Windows Cluster
Availability Group
Virtual
Network
EXAMPLE OF AVAILABILITY GROUP SPANNING
ON-PREMISE AND AZURE

WHAT IS SUPPORTED
Technology SQL Server
Version
Zero Data Loss Scop
e
#
Secondaries
Automatic
Failover
Readable
Secondarie
s
Availability
Groups
SQL Server 2012 Yes*
(Sync Mode)
DB(s) 4 Yes
(w/ additional
cluster
member)**
Yes
Database
Mirroring
SQL Server 2008
R2
SQL Server 2012
Yes*
(High Safety
Mode)
DB 1 Yes
(w/
Witness)**
Limited
(database
snapshots)
Log
Shipping
SQL Server 2008
R2
SQL Server 2012
No DB N No Limited
(standby
state)
* Most customers use Async Mode (High Performance) to avoid impacting primary performance
**Async Mode only supports Force Failover to make DR (and potential data loss) a conscious decision

WHY?
AVAILABILITY GROUPS
 Provide additional benefits:
• Integrated HA/DR
• Offload Read workloads to Azure
• Connect reporting/BI apps
• Migrate apps and run against local secondaries
• Offload Backups to Azure
• A solution for policy compliance
 Remember it requires:
• Same Windows Domain
• Needs an Active Directory Domain Controller

AGENDA
» Azure Blob Storage
» VM instance size and limits
» Types of Disks
» Disk Performance
» Virtual machine disk cache
» Best Practices
» Troubleshooting
» Disaster Recovery and High Availability

FREE TRIAL
• Try Database Performance Analyzer FREE for 14 days
• Quickly identify root cause of issues that impact end-user response time
• See historical trends over days, months, and years
• Monitor on-premise, on VMware®, in the Cloud, including Amazon® AWS and Azure™
virtual machines
• Agentless architecture, safe to use in production
33
RESOLVE PERFORMANCE ISSUES QUICKLY
© 2015 SOLARWINDS WORLDWIDE, LLC. ALL RIGHTS RESERVED.
www.solarwinds.com/dpa-download/

Questions?
(NOW IS THE TIME TO ASK THEM)

Thank You!
The SOLARWINDS and SOLARWINDS & Design marks are the exclusive property of SolarWinds Worldwide, LLC, are registered with the U.S. Patent and Trademark Office, and
may be registered or pending registration in other countries. All other SolarWinds trademarks, service marks, and logos may be common law marks, registered or pending
registration in the United States or in other countries. All other trademarks mentioned herein are used for identification purposes only and may be or are trademarks or registered
trademarks of their respective companies.

How to deploy SQL Server on an Microsoft Azure virtual machines

More Related Content

What's hot (19)

Viewers also liked (20)

Similar to How to deploy SQL Server on an Microsoft Azure virtual machines (20)

More from SolarWinds (20)

Recently uploaded (20)

How to deploy SQL Server on an Microsoft Azure virtual machines