Best Practices for
Virtualizing Mission
Critical Applications
Christopher Kusek, vExpert
Twitter: @cxi
Blog: http://pkguild.com
Housekeeping
• When tweeting about the sessions use #
• Include commentary in this session to @cxi
• Other housekeeping matters
Virtualizing Tier 1 is Impossible
Maturity begets virtualization
32-bit Windows
64-bit Windows
900MB Database Cache
32+ GB Database Cache
4Kb block size
8Kb block size
High read/write ratio
1:1 read/write ratio
*Not officially supported*
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
• EMC IT – 53,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
– Deploy with VMFS or Fixed Disk VHD
– Scale up and scale out
– Spread your CAS around
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 (VAAI, ODX)
– Per VHD / VMDK Locking
• Unlike in the physical world, most data stores
host more than one VM so account for that IO
• Auto-tiering with small granularity (768k) can
result in significant storage savings
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
Exchange Best Practices
• Size Exchange VMs to fit within NUMA nodes for
best performance
• Do not over commit memory unless absolutely
required
• Consider DAG for local site HA, and SRM for site
resiliency/DR
• Virtual machine backup products that rely on
virtual machine snapshots are not supported
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
– Use a capacity planner tool to assist
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
• 2012 switches to per core licensing!
• 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
SQL Failover Clustering Best Practices
• SQL Database Mirroring (SQL 2008) or AlwaysOn
Availability Groups (2012) can provide similar
levels of availability as failover clusters but
without the strict requirements or vendor
support issues.
• Most DBs have no failover capability not
clustered. By making them virtual and letting
them take advantage of vSphere HA (or the
Hyper-V equivalent) adds availability not
possible with physical servers
General Best Practices
• Best Practices for
– Memory
– CPU
– Networking
– Operations
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
– Use memory reservations for mission critical SQL
workloads to avoid memory contention issues.
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*
Operations
• Virtualizing Mission Critical Applications should
leverage Virtualization monitoring solutions like
– System Center
– vCenter Operations
Clusters
• Microsoft does not support migration of running
virtual machines running cluster software.
– Caveat*
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
• Twitter: @cxi
• Blog: http://pkguild.com