1. Strategic Reasons for Classifying Workloads for Tier 1 Virtualization. Why Classify? David Gallant, VMware Denis Larocque, MolsonCoors VAPP4842 #VAPP4842

2. 2 Agenda Introductions What is Workload Classification? Why Classification is important to Virtualizing Business Critical Applications Challenges and Opportunities Models Metrics, Tools, Modelling and Analysis Data Collection and Calculations Example Results MolsonCoors Use Case Classifying SAP Workloads Take Away Q&A 3. 3 Introductions Denis Larocque Infrastructure Architect - MolsonCoors 32 years experience in IT. Datacenter specialist accountable for server, storage and backup covering all datacenters around the world (Canada, US, UK , Central Europe). 12 years with SAP software 9 years with virtualization 4. 4 Introductions David Gallant Practice Solutions Architect Business Critical applications Practice, VMware Professional services 20 plus years experience architecting enterprise applications for fortune 500 companies. 7 years at SAP; technical architect for virtualization 5. 5 What is Workload Classification? In the simplest of terms, in the shortest definition: workload classification is measuring an application/database workload in an existing environment for placement in a new environment 6. 6 Why Classification is Important to Virtualizing Business Critical Applications BCA requires a cautious, methodical, planned and measured approach to stand up any new environments Workload Classification provides the proper analysis for sizing, placement, performance to speed up implementation, reduce downtime during migration and reduce risk. 7. 7 Challenges and Opportunities 8. 8 Challenges Multiple business units sharing a single instance Noisy neighbor databases Oversize as a safeguard Clustering is complicated Database not aligned properly with application and presentation layer 9. 9 Opportunities Each application has its own instance Dedicated performance profile Right sized VMware HA, FT, DRS, vMotion replaces clustering for most scenarios Proper 3 tier alignment 10. 10 Models 11. 11 ESXi Host Lift and Shift Model Migrate the entire database instance to a new virtual machine, size the VM to match the physical instance Advantages Easy to size the virtual machine Predictable performance Physical Machine Virtual Machine Database Instance Database Database Database Database Database Database Database Database Database Instance Database Database Database Database Database Database Database Database 12. 12 ESXi Host Classification Model Migrate the individual databases to new virtual machines that match the sizing requirements for that database Physical Machine Virtual Machine Virtual Machine Database Instance Database Database Instance Database Database Database Database Database Database Database Database Database Instance Database Database Database ESXi Host Virtual Machine Virtual Machine Database Instance Database Database Database Instance Database Database 13. 13 Metrics, Tools, Modelling and Analysis 14. 14 Metrics The 5 metrics: CPU Memory Storage Allocation Storage I/O Network I/O 15. 15 Data Collection Tools The Tools VMware Capacity Planner SAP Early Watch Alert Reports IBM Insight Reports Oracle AWR Microsoft MAPS Database Queries Windows PerfMon / Resource Monitor Linux / Unix NMON Top IOSTAT 16. 16 Modelling and Analysis Modelling and Analysis MS SQL Server or Oracle Database MS Excel Use Averages, Peaks Calculate Percentiles instead of Charts for large datasets Application dependency mapping is key to migration strategy and placement of workloads 17. 17 Source Server Metrics Metric Comments Total Server CPU MHz Number of physical CPU cores and MHz Speed SQL Instance Process Utilization A DMV query Database CPU Percent A DMV query Total Pages in Memory (MB) A DMV query converted to MB Database File IOPS A Perfmon Counter on a specific file Size on Disk Bytes A DMV Query or Script to track file size 18. 18 Target Server Metrics Metrics Comments Total Server CPU MHz Number of Physical CPU cores and MHz Speed Total Memory Physical Memory on Host Storage Tier IOPS IOPS rating for Storage Number of Hosts Use this as a multiplier for total solution 19. 19 An Example of One of the SQL Server DMVs Total Pages in Memory Converted to MBs SELECT db_name(database_id) as dbname, count(page_id) as pages, convert(decimal(20,2),count(page_id)*8192.0/1048576) as Mb from sys.dm_os_buffer_descriptors group by database_id order by convert(decimal(20,2),count(page_id)*8192.0/1048576) desc 20. 20 Network Profile Slow Network 21. 21 Data Collection and Calculations 22. 22 Data Collection and Calculations Item Data collection period Application dependency study Charts to graph data trends Percentiles versus averages 23. 23 Tips Stay away from using VM t-shirt sizing Collect data over a quarter end to get the peaks Use a virtual staging environment to right size the VM Follow SQL Server on vSphere Best Practices 24. 24 Example Results 25. 25 Example Calculations for a Single Database 26. 26 Example of the Capacity Map 27. 27 Use Cases Virtualizing: Database instances where multiple databases reside for non common applications Many database instances supporting a single application Any 3 tier applications SAP landscapes 28. MolsonCoors Datacenter Migration/ SAP landscape refresh Virtualize new SAP landscape Insert photo here 29. MolsonCoors Virtualize new SAP landscape From beginning to end: What to do ? Buy bigger/spend more $ Or Do it intelligently: plan it and save $ Why virtualize Assess current state/system Timeframe/scope Design new landscape 30. MolsonCoors Why virtualize Reduce hardware dependency Transparent maintenance window for firmware upgrade New possibilities Disaster recovery Temporary copy/snapshot for test/training Hot add (CPU/memory) Save on next refresh cost Next refresh will be focus on business need and not technology trend 31. MolsonCoors Assess current state/system Peak CPU utilization stat (over long enough representative period) SAPs measurement (from SAP or hardware vendor) Memory footprint Software compatibility/upgrade Version of SAP module that support virtualization - Make upgrade prior to hardware refresh to reduce risk 32. MolsonCoors Timeframe/Scope Take into consideration new technology OS Printing Security Be realistic Time to test Time to establish standard for new platform 33. MolsonCoors Design new landscape Hardware sizing Powerful new building block 34. MolsonCoors Design new landscape Config/setup/option Hyper-threading FT requirement and restriction 1 cpu / 64GB of memory Max 4 FT VMs per host ESX Farm Production vs development, SAP vs non SAP Reservation for SAP VMs DRS Rules for apps/DB same SAP instance, different host Disk VMDK vs RAW - Snapshot, Backup, Limitation of 256 LUNs host 35. MolsonCoors Basic principle to include into design Think virtual From top to bottom Size farm not each individual host Resilience/Maintenance N-1 Peak load Validate with Expert 36. Calculation example Legacy Prod SAPs Peak cpu load actual workload (SAPs) 30% growth run at 60% capacity total SAPs/Tie r (target) % SAPs/Tier current SAPs/tier GB GB/Tier Server 1 db 23,333 65 15,166 19,716 27,603 128 Server 2 db 23,333 70 16,333 21,233 29,726 128 Server 3 db 23,333 50 11,667 15,166 21,233 78,562 40% 43,166 128 384 Server 4 app 23,333 100 23,333 30,333 42,466 192 Server 5 app 23,333 70 16,333 21,233 29,726 192 Server 6 app 23,333 70 16,333 21,233 29,726 192 Server 7 app 23,333 35 8,167 10,617 14,863 116,782 60% 64,166 128 704 163,331 107,332 139,531 195,344 195,344 107,332 1,088 1.3 1.4 New PROD Operation with minus 1BL660 SAPS no vcpu SAPS/vcpu Memory quantity total SAPS total vcpu total SAPS total vCPU memory memory BL460 mix 40,180 32 1,256 256 6 241,080 182 241,080 182 1,536 1,536 BL660 mix 68,630 64 1,072 512 2 137,260 122 68,630 61 1,024 512 8 378,340 304 309,710 243 2,560 2,048 CPU Memory Operation with minus 1BL660 37. Calculation example System Prod %total load relative DB SAPS apps SAPS # vcpu for db #cpu for apps #vcpu for CI with FT MII IP9 Java 5.39 4,235 6,295 4 6 2 ECC - 6.0 RP1 ABAP 11.26 8,846 13,150 9 13 2 WMS (ECC) RP5 ABAP 10.78 8,469 12,589 8 12 2 BI Abap - 7.3 BP2 ABAP 12.97 10,190 15,147 10 15 2 BI Portal - 7.3 JP1 Java 2.69 2,113 3,141 2 3 2 CRM - 5.0 CP9 ABAP 6.74 5,295 7,871 5 8 2 Ent Portal PP1 Java 1 786 1,168 1 2 2 Sol Man MP1 ABAP / Java 3.37 2,648 3,936 3 4 4 ECC - 6.0 RP9 ABAP 11.79 9,262 13,769 9 13 2 LiveCache LP8 n/a 4.36 3,425 5,092 4 5 0 MDM - Portal JP9 Java 1 786 1,168 1 2 2 MDM - Server KP9 C++ 1 786 1,168 1 2 0 SCM - 5.0 AP8 ABAP 6.71 5,272 7,836 5 8 2 SCM - 5.0 Project AP9 ABAP 6.43 5,052 7,509 0 0 0 SRM - 5.0 SP9 ABAP / Java 6.08 4,777 7,100 5 7 4 XI / PI - 7.01 XP9 ABAP / Java 5.74 4,509 6,703 5 7 4 SLD DP9 Java 2.69 2,113 3,141 2 3 2 100 78,562 116,782 74 110 34 total SAPS 195,344 tot vcpu 218 targetted targetted 38. 39 Take Away Workload classification takes time to save time, money and risk 39. 40 Questions 40. 41 VMware Professional Services VMware, Inc. 3401 Hillview Ave Palo Alto, CA 94304 Tel: 1-877-486-9273 or 650-427-5000 Fax: 650-427-5001 41. THANK YOU 42. Strategic Reasons for Classifying Workloads for Tier 1 Virtualization. Why Classify? David Gallant, VMware Denis Larocque, Molsoncoors VAPP4842 #VAPP4842