This document discusses the importance of classifying workloads before virtualizing tier 1 applications. Workload classification involves measuring existing application and database workloads to properly size and place them in a new virtualized environment. This reduces risks and speeds up implementation by providing the proper analysis. The document outlines challenges, opportunities, models, metrics, tools and an example MolsonCoors used workload classification to virtualize their SAP landscape.

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 DMV’s – 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

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