Best Practices for Virtualizing Mission Critical Applications

1. Best Practices for Virtualizing Mission Critical Applications Christopher Kusek @cxi Global Virtualization Lead EMC Consulting Blog: http://pkguild.com

2. When tweeting about the sessions use #TEC2012 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  Housekeeping

3. Virtualizing Tier 1 is Impossible

5. Maturity begets virtualization

6. 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

7. Where do I start?

8. 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!

9. 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

10. 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!

11. 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

12. 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

13. 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

14. 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

15. 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

16. Get on the road to Virtual SQL

17. 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!

18. 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

19. 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!

20. Virtualized SQL is blazing fast!

21. 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

22. 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

23. 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

24. 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

25. 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

26. 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

27. 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%

28. 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

29. 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

30. General Best Practices Best Practices for Memory CPU Networking Operations

31. Memory is Key

32. 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.

33. 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

34. 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

35. Can has more CPU

36. 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

37. FCoTR is the key to the future

38. Networking Best Practices Separate LiveMotion/vMotion, Logging and console traffic; or use VLAN tagging Use a paravirtualizedvNIC 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*

39. Operations Virtualizing Mission Critical Applications should leverage Virtualization monitoring solutions like System Center vCenter Operations

40. Clusters Microsoft does not support migration of running virtual machines running cluster software. Caveat*

41. Alignment Ensure your VMs have their disks aligned Boot alignmentis auto in 2008, manual in 2003 Application LUN is manual, follow application and storage vendor best practices

42. Thank you!

43. 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

44. Credits Christopher Kusek, vExpert, CISSP, MCT EMC Consulting Global Virtualization Lead Twitter: @cxi Blog: http://pkguild.com