1. ©202 BMC Software, Inc. All Rights Reserved. Server Consolidation Eric D. Ho Advisory Software Consultant BMC Software, Inc. March 20, 2002

2. 2 Objective  This presentation is designed to show the methodology by which server consolidation study can be achieved using PATROL Perform and Predict.

3. 3 Server Consolidation Advantages Reduced total cost of ownership  Lower license cost for software  Improved system manageability System backup and recovery Software distribution Reduce manpower requirements  Improve infrastructure technology Replace older servers with newer technology Faster processors will reduce workload response times and memory requirements

4. 4 Server Consolidation Challenges Need to:  Measure current usage accurately  Capture the configuration details  Characterize workloads  Understand usage patterns  Predict the consolidation effect  Evaluate alternatives  Project growth

5. 5 Server Consolidation Risks You don’t know where to start !!  Methodology, Process, Tools Wrong Size - It does not fit !!  Oops! Career change? It fits! But.. Performance stinks  Buy more…. Spend more! It will take a long time !!  By the time you are done, the solution is obsolete.

6. 6 Server Consolidation Methodology Six steps to Success  1. Baseline current performance Collect detailed performance data  2. Characterize w orkload System, utility, application, database, etc.  3. Analyze resource usage level Time Series Graphical Analysis Peaks, batch windows, trends, growth pattern Workloads profiles  4. Combine systems for sizing Server and Workload stacking  5. Consolidation m odeling Resource contention analysis Response time degradation analysis Growth sensitivity analysis  6. Validate recommendation

7. 7 1 - Baseline Current Performance Collect detailed performance metrics  System, IO, memory, process, user  24x7  Data collected every 10 seconds  Data logged every 15 minutes 96 data records per day per server Servers: as10, db02, db14, db15, and db25

8. 8 PATROL Data Collection PATROL AGENT PATROL Collector OS KM Perform AGENT Proactive Monitoring Thresholds Status/Alerts Detect Problems Recovery Actions Availability Problem Determination Problem Resolution Proactive Planning Performance Check Workload Analysis Bottleneck Analysis Performance Reporting Predictive Analysis Capacity Planning Kernel Data PATROL History File Daily Performance Files

9. Visualizer Reports Visualizer (Windows-based) Graphical Analysis Analyze Performance Analysis Predict Predictive Analysis UNIX NT UNIX or NT Investigate UNIX and NT Real-Time Analysis Visualizer Database PATROL Perform & Predict Architecture PATROL Collect Performance Model Performance Results TCP: 6767, 6768 TCP: 10128

10. 10

11. 11

12. 12 2. Workload Characterization Logical Grouping  Who (users)  What (processes)  Where (servers) Dynamic  Post Data Collection Business Perspective  Application  Business Unit/Budget  Geographic SystemsUsers Transactions Workloads

13. 13 Sample Workloads Characterize workloads  Oracle (1 process = 1 transaction)  axciom (Oracle Instance MEMPWD)  f45 (Oracle Financials Form 45)  f60 (Oracle Financials Form 60)  ar25run  RGRAGR  PMSERVER  GL  tools (BMC, HP, etc.)  system  zzz (the rest of processes)

14. 14 3 - Analyze Resource Usage Level  (A) Time Series Graphical Analysis Peaks Batch windows Trends Growth pattern  (B) Workload Analysis

15. 15

16. 16

17. 17

18. 18

19. 19 3 - Analyze Resource Usage Level  (A) Time Series Graphical Analysis Peaks Batch windows Trends Growth pattern  (B) Workload Analysis

20. 20 as10  HP N4000/06, 440 MHz  14 GB memory  Peak Utilizations from 9am-10pm 1pm-2pm Major Workloads  dis4ws  f45  f60 Workload Analysis - as10

21. 21 db02  HP V2500/20,  440 MHz  12 GB memory  Peak Utilization: 7am-7pm Major Workloads  Oracle  RGRARG Workload Analysis - db02

22. 22 db14  Sun F6800/08, 750 MHz  16 GB memory  Peak Utilization from 6pm-12am Major Workload  Oracle Workload Analysis - db14

23. 23 Workload Analysis - db15 db15  Sun F6800/08, 750 MHz  16 GB memory  Peak Utilization from 1pm-7pm Major Workload  Oracle-Axciom

24. 24 db25  Sun E4500/06, 440 MHz  6 GB memory  Peak Utilization: 5pm-10pm Major Workload  Oracle Workload Analysis - db25

25. 25 4 - Combine Systems for Sizing  Server stacking Combined as10 and db02 into 1 server  Change db02 from HP to Sun F6800 Combined 2 database servers (db14 and db25) into 1 server  Workload stacking Stack up all Oracle Instances  Check total capacity requirement  Use graphical visualization for quick check!

26. 26 Server Stacking  Stacked as10 and db02 servers  Total CPU requirement is about 1200%  12 processors needed?

27. 27 Server Stacking  Stacked 3 database servers into 1  Total CPU requirement is less than 1000% (10 processors)  IO issue?  Paging issue?

28. 28 Workload Stacking  Stacked all Oracle workloads into 1 server  Total CPU requirement is slightly over 800% (on 8 processors)

29. 29 5 - Consolidation Modeling  Resource contention analysis Combined as10 and db02 into 1 server  Change db02 from HP to Sun F6800/16 @750 MHz Consolidate Workloads from db14 and db25 into db14  Response time degradation analysis  Growth sensitivity analysis Use 3/18/2002 14:00 to 15:00 as baseline interval Let’s see how PATROL Predict works…...

30. 30 Baseline Model: Mar-18-2002, 14:00 Prepare the baseline model  Build a model for all nodes at peak utilization  Calibrate the models to ensure measured and calculated values are accurate.

31. 31 Baseline Analysis - Response Time Note:  Response Time corresponded to transaction turnaround time  Relative Response Time was set to 1. Any “what-if” scenarios would change the Relative Response Time to reflect improvement or degradation

32. 32 Baseline Analysis - Utilization Note:  This report shows the current workload breakdown of as10and db02  We would “move” the application workloads from as10 to db02 as part of the server consolidation.

33. 33 Baseline Analysis Note:  This report shows the current workload breakdown of db14, db15 and db25  We would “move” the application workloads from db25 to db14 as part of the server consolidation.

34. 34 What-if Analyses  Growth Sensitivity Analysis  Server Sizing Application Server Database Server…  Application Sizing  Disaster Planning  Hardware Purchase Planning  Capacity Planning

35. 35 Consolidation Modeling #1  Resource contention analysis Combined as10 and db02 into 1 server  Change db02 from HP to Sun F6800/16 @ 750 MHz Used 3/18/2002 14:00 to 15:00 as baseline interval

36. 36 What-if Modeling - Utilization Note:  This report shows the workloads f45, f60, dis4ws and rw- procs were moved from as10 to db02.  Next, we would look at the relative response time changes.

37. 37 What-if Modeling - Response Time Note:  This report shows the workloads f45, f60, dis4ws and rw- procs about 27% slower after they were moved.  The reason is that db02 has slower processor speed (25.27 specint95 per processor) than as10 (32.96 specint95), even though it has 20 processors versus 6 processors at as10.  Let’s see what happened when db02 is changed to a SUN F6800/16 machine.

38. 38 Note:  This report shows effect of the server upgraded.  The moved workloads are now 90% of the original time.  The oracle workload is now improved by 25%.  SUN F6800/16 at 750 Mhz is rated at 35.34 specint95 per processor)

39. 39 Consolidation Modeling #2  Resource contention analysis Consolidate Workloads from db14 and db25 into db14 Used 3/18/2002 20:00 to 21:00 as baseline interval since db14 and db25 had higher utilization at night time.

40. 40 Workload Migration - Utilization Note:  This report shows the Oracle@db25 moved to db14.

41. 41 Workload Migration - Response Time Note:  This report shows the Oracle@db25 workload running at db14 received a 41% improvement on response time.  Original workloads on db14 were not affected by the moved Oracle workload

42. 42 6 - Validate Recommendation  Create test environment  Observe results of initial implementation  Compare modeled results with “consolidated” measurement.  Re-model the combined systems to account for un-foreseen changes

43. 43 Server Consolidation Review Six steps to Success  1. Baseline current performance Collect detailed performance data  2. Characterize w orkload System, utility, application, database, etc.  3. Analyze resource usage level Time Series Graphical Analysis Peaks, batch windows, trends, growth pattern Workloads profiles  4. Combine systems for sizing Server and Workload stacking  5. Consolidation m odeling Resource contention analysis Response time degradation analysis Growth sensitivity analysis  6. Validate recommendation

44. 44 STORAGE Consolidation Too? BMC’s Application Centric Storage Management (ACSM) products can be leveraged to consolidate the storage side…

45. 45 PATROL Performance Management Summary An established process  An integrated suite of products and services to manage mission critical client/server applications. A proven methodology  Performance and capacity management across multiple platforms Multi-functional  Performance Analysis  Daily Performance Visualization  Interactive Performance Prediction High degree of process automation

46. 46 ROI’s Ensure consistent approach to take on server consolidation projects  ROI: Reduce risks and costs Enable IT staff to understand performance information and evaluate alternatives effectively  ROI: Better IT Performance/$ Ratio Empower IT staff to plan for and justify expenditures with confidence  ROI: Timely hardware/software acquisitions