Transcript Slides delivered for The Experts Conference 2011 #TEC2011 Session

Best Practices for
Virtualizing Mission
Critical Applications
Christopher Kusek @cxi
Blog: http://pkguild.com
Housekeeping
• When tweeting about the sessions use #TEC2011
• Include commentary in this session to @cxi
• For voting commentary feel free to vote by adding
– #cxirocks
– #cxisucks
– Be sure to add some constructive feedback to your vote 
Virtualizing Tier 1 is Impossible
Maturity begets virtualization
32-bit Windows
900MB Database Cache
4Kb block size
High read/write ratio
64-bit Windows
32+ GB Database Cache
8Kb block size
1:1 read/write ratio
70% reduction in disk I/O
64-bit Windows
32Kb block size
I/O pattern optimization
I/O reduced 50% more
Who ran first so I can run too?
•
•
•
•
United States Navy/Marine Corps – 750,000 mailboxes
University of Plymouth – 40,000 mailboxes
VMware IT – 9,000 very heavy mailboxes
University of Texas at Brownsville – 25,000 mailboxes
Where do I start?
Virtual Exchange Start here
• Refer to Support Policies, Recommendations
and Best Practice Documents
• Architect for the application, not for the
virtualization solution
• Pretend like you’re doing it physically… and
Just do it virtually
• Defaults unless requiring optimization!
Start Simple
• Deploy VMs with similar roles on separate
hosts
– MBX VMs in same DAG should not co-locate
– Spread your CAS around
– Deploy with VMFS or Fixed Disk VHD
– Scale up and scale out
Licensing Exchange in the Virtual!!!
• One server license is required for each running
instance of Exchange Server 2010 – whether it
is installed natively on a physical machine or
on a virtual machine
• That’s pretty simple!
Configure Storage
• Review the Exchange Calculator to determine
your memory, spindle and IOPS requirement
• Configure your storage how you would handle
it physically, then present it to your VMs
• Size your MBX VHD or VMDK <2TB
– Some suggest 2040GB to be on the safe side
Configure Storage Continued
• Array Snapshots for any virtualization vendor
are not supported with Exchange Server
– Support and supportability needs to be supplied
by your storage vendor
• Live Migration and VMotion are supported
with Exchange Server, but not with DAGs*
• Do exactly the same virtually as you would
physically when it comes to allocation
Configure Storage Continued
• Take advantage of “Optimized for
Virtualization” acceleration technologies by
storage vendors
– Storage Offloading
– Per VHD / VMDK Locking
• Unlike in the physical world, most data stores
host more than one VM so account for that IO
Exchange Best Practices
• Do not P2V your Exchange Servers
– Build new servers virtually and move mailboxes
• Split your roles and size their CPU/Mem on a
role by role basis
• Analyze performance characteristics before
and after if performing migration
• Less physical servers != fewer resources
Get on the road to Virtual SQL
Virtual SQL Start here
• Refer to Support Policies, Recommendations
and Best Practice Documents
• Architect for the application, not for the
virtualization solution
• Pretend like you’re doing it physically… and
Just do it virtually
• Defaults unless requiring optimization!
Start Simple
• The average physical SQL Server uses 2 CPUs is
6% utilized, 3Gb Mem, 60% utilized, ~20 IOPS
• Light workload?
– Start with 2vCPUs, 3Gb ram
• Heavy workload?
– Start with 4vCPUs, 8Gb+ ram
• Really Heavy workload?
– Architect as if physical in the virtual
Licensing SQL in the Virtual?!?
• Standard, Workgroup, Enterprise per proc
– You must license SQL for each virtual processor
• Standard, Workgroup per Server/CAL
– You must license each virtual operating system
• Enterprise per physical proc
– Licensing each physical processor entitles you to
run any number of SQL server instances
• Unsure? Contact licensing professionals!
Virtualized SQL is blazing fast!
Configure Storage Correctly
• Database LUN needs enough spindles
• Log LUN needs enough spindles
• Mixing sequential (logs) and random
(database) can result in random behavior
– Avoid mixing workloads, refer to storage vendor
• Fixed-size VHD or Eager-Zeroed Thick VMDK
for your Database and Log volumes
Configure Storage Continued
• Array Snapshots for any virtualization vendor
are not supported with SQL Server
– Support and supportability needs to be supplied
by your storage vendor
• Live Migration and VMotion are supported
with SQL Server
• Do exactly the same virtually as you would
physically when it comes to allocation
Configure Storage Continued
• Try to leverage Array Tiering and Acceleration
technologies if possible
– Use Array based caching to improve performance
• Most DBs, even High IO ones are hot ~10-15%
of the database, the rest is cold IO
– Automatic Tiering makes for higher performance
and higher efficiency while reducing cost
Migrating SQL
•
•
•
•
•
Analyze your existing environment
Perform a virtualization assessment
Pay attention to disk spindles not total space
Easy Migration: Use converter to clone server
Easier mgmt and provisioning: Use Templates
Database Best Practices
•
•
•
•
•
•
•
Follow Microsoft Best Practices for SQL Server
Evaluate workloads for SQL-intensive ops
Consider ScalingOut for high end deployments
Defrag SQL Databases
Design back-end to support workload (IOPS)
Monitor DB/Logs for Disk r/w, Disk Queues
Use Fibre-channel connectivity for storage
Configuring Physical Files
• Os/App, Data, Log and TempDB on separate
spindles – Separate LUNs on single datastore
will not provide IO separation
• Use RAID10 or RAID5 (read-only)
– Refer to your storage vendors best practices
• Pre-size data files, do not AUTOGROW
• Pre-size log files, ~10% of DB on average
Configuring TempDB
•
•
•
•
•
•
Move TempDB to dedicated LUN
# of TempDB files = # of CPU cores
All TempDB files should be equal in size
Pre-Allocate TempDB space for workload
Set file growth increment to minimize expand
Microsoft recommends FILEGROWTH incr 10%
SQL Failover Clustering Best Practices
• Failover clustering is supported with caveats
– Follow best practices guide for SQL Clustering
– Use RDMS for DB and Log volumes
– Use eagerthickzeroed disks
– Use separate vSCSI controller for OS and Data
– Use separate vSwitches for Public and Heartbeat
– Team NICs for network redundancy
General Best Practices
• Best Practices for
– Memory
– CPU
– Networking
Memory is Key
Memory Practices
• Allocate your memory based upon your
application workload
• Database memory doesn’t dedupe well
• Do not over subscribe mission critical
workloads
• Do NOT OVER SUBSCRIBE MISSION CRITICAL
WORKLOADS
Hyper-V and Memory
• Hyper-V Dynamic Memory is fully supported
with SQL Server. Only SQL Server versions and
editions (Enterprise and Datacenter) that
support Hot Add Memory can see memory
that is added by using Hyper-V Dynamic
Memory
• Exchange Server doesn’t change memory on
the fly – No real value to enable
VMware and Memory
• Enable memory ballooning and memory page
sharing
• Do not over-commit memory
• Set memory reserves to match VM config
– Setting reservations could limit vMotion
• Enable DRS* where supported
• Avoid swapping by configuring VM with
greater than average memory usage
Can has more CPU
CPU Practices
• Only allocate vCPUs which are being used
– Idle vCPUs will compete for system resources
• If workload is unknown, size for fewer vCPUs
– You can always add more later if reqs demand
• For Performance Critical VMs
– Try to ensure total number of vCPUs assigned to
all VMs is <= total number of cores on the host
– CPU load average of <=1. If greater, add more cpu
FCoTR is the key to the future
Networking Best Practices
• Separate LiveMotion/vMotion, Logging and
console traffic; or use VLAN tagging
• Use a paravirtualized vNIC for high
performance workloads
• Leverage 802.1q using Virtual Switch Tagging
(VST). - VST is most common configuration
• Follow networking design guidelines
• Do NOT use Jumbo Frames*
Clusters
• Microsoft does not support migration of
running virtual machines running cluster
software.
– Caveat: Internal testing and customer POCs have
found no affect on operation of cluster members
Alignment
• Ensure your VMs have their disks aligned
– Boot alignment is auto in 2008, manual in 2003
– Application LUN is manual, follow application and
storage vendor best practices
Thank you!
Links if you don’t see presenter notes!
•
•
•
•
•
Microsoft Support Policies and Recommendations for Exchange Servers in Hardware Virtualization Environments
Exchange 2010 on VMware - Best Practices Guide
http://www.vmware.com/pdf/Virtualizing_Exchange2003.pdf
http://www.vmware.com/files/pdf/solutions/08Q4_VM_Exchange_Server_2007_VI3_WP.pdf
http://www.vmware.com/files/pdf/Exchange_2010_on_VMware_-_Best_Practices_Guide.pdf
•
•
•
•
Microsoft Virtualization Best Practices for Exchange
HP recommended configuration for Exchange Server 2010 and Hyper-V R2 for 5,000 users
Exchange Server 2007 and Hyper-V: Best Practices Blog Post
Policies and Recommendations for Exchange Servers in Virtualization Environments
•
•
•
•
Refer to these great blog series which covers Exchange and VMware
http://www.clearpathsg.com/blogs/2010/07/13/exchange-2010-vsphere-4-best-practices-part-1
http://www.clearpathsg.com/blogs/2010/07/29/exchange-2010-vsphere-4-best-practices-part-2
http://www.clearpathsg.com/blogs/2011/01/13/exchange-2010-vsphere-4-best-practices-part-3
•
•
Duncan Epping
http://www.yellow-bricks.com/2008/12/17/exchange-2007on-vmware/
•
•
•
•
•
•
•
•
Best Practices for SQL Server with VMware
Microsoft SQL Server and VMware Virtual Infrastructure Best Practices
Running SQL in a Hyper-V Environment
Consolidation Guidance for SQL Server
High Performance SQL Server Workloads on Hyper-V
SQL Server 2008 on Hyper-V - Best Practices & Performance
Licensing SQL
Alignment
Credits
•
•
•
•
Christopher Kusek, vExpert, CISSP, MCT
Technology Evangelist
Twitter: @cxi
Blog: http://pkguild.com
• Yes that is my tiny head!