IBM EAS Technical White Paper

IBM Americas Advanced Technical Support IBM EAS Technical White Paper Capacity on Demand: 2 – 4 Way Systems Dynamic LPAR Examples for SAP Mark Gordon Phil Hardy IBM EAS Advanced Technical Support Version: 1.1 Date: August 3, 2003 Capacity on Demand: 2 – 4 Way Systems Dynamic LPAR Examples for SAP Page 1 of 14 IBM Americas Advanced Technical Support 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. The DLPAR Opportunity:................................................................................................................... 3 The Test Objective:............................................................................................................................. 3 Trademarks: ........................................................................................................................................ 3 Acknowledgements............................................................................................................................. 3 Feedback: ............................................................................................................................................ 3 The Test Environment: ....................................................................................................................... 3 The Tests:............................................................................................................................................ 4 The Results: ........................................................................................................................................ 5 Conclusions:...................................................................................................................................... 11 Appendix A – Dynamic CPU Reconfiguration: ........................................................................... 12 Appendix A – Dynamic Memory Reconfiguration: ..................................................................... 13 Capacity on Demand: 2 – 4 Way Systems Dynamic LPAR Examples for SAP Page 2 of 14 IBM Americas Advanced Technical Support 1. The DLPAR Opportunity: Dynamic LPAR (DLPAR) enables one to make dynamic processor and memory configuration changes in an LPAR. The ability to dynamically modify the number of CPUs as well as available memory can offer benefits in managing resources and in responding to changing processing requirements. For businesses, this can provide a previously unavailable flexibility in their operations, by giving an organization the ability to move processor and memory resources to where they are needed most at a given point in time. E.g., after the completion of the online day SAP BW processing, processors may be reallocated to a partition wherein the nightly batch processing is scheduled. The process of dynamically changing the number of processors and amount of memory is straightforward, and enables organizations to effectively address these resource issues in a timely manner, moving processors and memory to where they are most needed. This reduces the pressure to configure the processor and memory requirements for each LPAR for the heaviest peak processing loads – systems can be configured more to the point of addressing overall system processing loads, with the knowledge that resources can be reallocated to an LPAR when its peak period processing is required, by moving resources from LPARs that don’t need them. 2. The Test Objective: Our objective was twofold: • • Illustrate workload scalability by adding processors and memory to an LPAR; and, Illustrate that the DLPAR changes do not disrupt the running workload. The framework for the tests was to run a standard workload on 2 and 4 way systems with scaling to > 80% utilization. Then, using DLPAR, add additional CPU and memory resources to enable workload to grow, and remove them when the workload no longer required them. 3. Trademarks: SAP and R/3 are trademarks or registered trademarks of SAP A.G. DB2, AIX, Universal Database, and UDB are trademarks or registered trademarks of IBM Corp. 4. Acknowledgements: Thank you to Joerg Droste and Pete Jordan, who installed, configured, and supported the test environment. 5. Feedback: Please send comments or suggestions for changes to gordonmr@us.ibm.com or pjhardy@us.ibm.com. 6. The Test Environment: The test was done on an IBM pSeries machine running AIX 5.2 with DLPAR. A two-tier SAP R/3 system, where the SAP application server runs with the database, provided the application framework. DB2/UDB version 8 was used as the database for the SAP R/3 system. For DLPAR, WebSM was used to communicate Capacity on Demand: 2 – 4 Way Systems Dynamic LPAR Examples for SAP Page 3 of 14 IBM Americas Advanced Technical Support with the HMC to manage the processor and memory resources for the tests. (WebSM is a web based set of system management interfaces, installed for these tests on a PC, that was used to control the HMC.) The hardware: Two LPARs on an IBM pSeries machine, with a total of 14 GB of memory and 6 processors. The database and SAP system resided in one LPAR, and the workload driver residing in the other LPAR. The application: An SAP R/3 release 4.6D system, with a test workload providing a repeatable load on the system. The application processing load was provided by controlled groups of simulated users that serially logged on, generated an online transaction workload, and subsequently logged off. 7. The Tests: There were two test processes. For each test, the processor and memory allocations were set at starting points, and then modified as the workload in each test ran through its cycle. The test cycles were short, to demonstrate the concept. Memory and processors were added and removed in less than an hour. While this cycle time is technically feasible, in general we would expect that resources might be moved within a daily, weekly, or monthly processing cycle. For the first test, where only the number of processors was modified as the workload changed, the test cycle consisted of the following: • • • • • The start, where an initial number of simulated users login to a 2-way LPAR and issue transactions, resulting in low CPU utilization; Additional simulated users start, and the SAP system starts to become CPU constrained; Two processors are added to the LPAR to relieve the CPU constraint; Additional users are started to drive higher workload levels in the 4-way LPAR; and, After the set of simulated users that generated the high 4-way CPU utilization completed the processing cycle, two processors are removed from the LPAR. The results from this scenario demonstrate the flexibility of DLPAR: An increase in CPU capacity enables the application to drive a higher workload, and a reduction in the workload allows a decrease in the CPU capacity. For the second test, where the test dynamically modified the amount of memory in addition to changing the number of processors, the test cycle was: • • • • • • The start, where CPU and memory are nearly fully utilized; Processors and memory are added to the LPAR to support additional users; Additional simulated users are started, with the expected increase in dialog steps per minute and increase in the amount of memory used; As the second set of simulated users complete processing, memory usage decreases; When the second set of simulated users completes, and the CPU and memory demand has reduced to the initial state, the processors and memory that were added to the LPAR are removed; and, The baseline set of simulated users continues running. Capacity on Demand: 2 – 4 Way Systems Dynamic LPAR Examples for SAP Page 4 of 14 IBM Americas Advanced Technical Support There were two equal groups of simulated users for this second test. The first group was started and continued in a steady state of processing throughout the test. The second group was started after the first group, reached the peak workload, and then completed its cycle leaving the initial group running. 8. The Results: The following graphs illustrate the results. In order of inclusion: 1. Figure 1: Test 1 - Processors Available and Used – When additional processors are made available to the LPAR and the workload increases, overall CPU utilization for all processors in the LPAR increases. 2. Figure 2: Test 1 - Dialog Step Scaling - Illustrates the workload scalability by the increase in dialog steps processed each minute when the number of processors is increased from two to four. 3. Figure 3: Test 1 - CPU Usage and Response Time – Shows the relationship of dialog response time and CPU utilization as both the workload changes and processors are first added, and then removed, during the test cycle. 4. Figure 4: Test 1 - Individual Processor Usage – CPU utilization as two processors are added, and then removed, from the LPAR. 5. Figure 5: Test 2 - Memory added to support additional workload – As the workload increases to support an additional group of simulated users, so does the number of memory pages used. Capacity on Demand: 2 – 4 Way Systems Dynamic LPAR Examples for SAP Page 5 of 14 IBM Americas Advanced Technical Support Processors Available and Used 4.50 4.50 4.00 4.00 3.50 3.50 3.00 Processor Usage 3.00 Processors in LPAR 2.50 2.50 2.00 2.00 CPUs Available CPUs Used 1.50 1.50 1.00 1.00 0.50 0.50 0.00 :1 1 11 :01 :1 4 11 :01 :1 7 11 :01 :2 0 11 :01 :2 3 11 :01 :2 6 11 :01 :2 9 11 :01 :3 2 11 :01 :3 5 11 :01 :3 8 11 :01 :4 1 11 :01 :4 4 11 :01 :4 7 11 :01 :5 0 11 :01 :5 3 11 :01 :5 6 11 :01 :5 9 12 :01 :0 2 12 :01 :0 5 12 :01 :0 8 12 :01 :1 1: 01 0.00 11 Time of Day Figure 1: Test 1 - Processors Available and Used Beginning with two processors, the workload scales up to a CPU constraint. Adding two processors at 11:29 enables the workload to scale as new users start using more CPU. After the additional workload is finished, the two additional processors are removed at 11:53. This shows the workload scalability that can be achieved with DLPAR. Capacity on Demand: 2 – 4 Way Systems Dynamic LPAR Examples for SAP Page 6 of 14 IBM Americas Advanced Technical Support Dialog Step Scaling 3,500 4.50 3,000 4.00 3.50 2,500 3.00 2,000 CPUs in LPAR Dialog Steps 2.50 1,500 2.00 # Steps CPUs Available 1.50 1,000 1.00 500 0.50 0 :1 1 11 :01 :1 4 11 :01 :1 7 11 :01 :2 0 11 :01 :2 3 11 :01 :2 6 11 :01 :2 9 11 :01 :3 2 11 :01 :3 5 11 :01 :3 8 11 :01 :4 1 11 :01 :4 4 11 :01 :4 7 11 :01 :5 0 11 :01 :5 3 11 :01 :5 6 11 :01 :5 9 12 :01 :0 2 12 :01 :0 5 12 :01 :0 8 12 :01 :1 1: 01 0.00 11 Time Figure 2: Test 1 - Dialog Step Scaling This graph is similar to Figure 1. It shows that when throughput was limited with two processors, the number of dialog steps per minute could increase when two additional processors are added to the LPAR. When the number of dialog steps per minute decreased, and the CPU demand decreased, the additional processors were removed from the LPAR. Capacity on Demand: 2 – 4 Way Systems Dynamic LPAR Examples for SAP Page 7 of 14 IBM Americas Advanced Technical Support CPU Usage and Response Time 100 90 80 70 60 50 40 30 100.0 20 10 0 :0 1 :0 1 :0 1 :0 1 :0 1 :0 1 :0 1 :0 1 :0 1 :0 1 :0 1 :0 1 :0 1 :0 1 :0 1 :1 1 :1 5 :1 9 :2 7 :2 3 :3 1 :3 5 :3 9 :4 3 :4 7 :5 1 :5 5 :5 9 :0 3 :0 7 :1 1 :0 1 Dialog Step Average Response Time CPU Usage (percentage of LPAR) Group 1: 0 users scale up to 190 users Group 2: Add 190 users to peak of 380 and back to 190 Group 1 continues: 190 Users ramp down to 0 400.0 350.0 300.0 250.0 200.0 CPU/glkern CPU/gluser Ø Time 150.0 Add 2 CPUs Remove 2 CPUs 50.0 0.0 11 11 11 11 11 11 11 11 11 11 11 11 11 12 12 Time of Day Figure 3: Test 1 - CPU Usage and Response Time On the left part of the chart, as the number of users in Group 1 increase, the CPU usage and dialog response time increases. When two additional processors are allocated to the LPAR, CPU utilization and dialog response time initially drop, and then begin to increase as Group 2 of the simulated users is added. As the second group of simulated users completes processing, CPU utilization and dialog response time begin to decrease. Continuing, when the two additional processors are removed from the LPAR, both the utilization on the remaining CPUs and dialog response time initially increase to reflect the reduced resource. Finally, the dialog response time and CPU utilization both decrease as the initial set of users complete the processing cycle. Capacity on Demand: 2 – 4 Way Systems Dynamic LPAR Examples for SAP 12 Page 8 of 14 IBM Americas Advanced Technical Support Individual Processor Usage 450 400 350 300 250 200 150 100 50 0 4.50 4.00 3.50 CPU/cpu3/kern 3.00 Processors 2.50 2.00 1.50 1.00 0.50 0.00 CPU/cpu3/user CPU/cpu2/kern CPU/cpu2/user CPU/cpu1/kern CPU/cpu1/user CPU/cpu0/kern CPU/cpu0/user CPUs Available Sum of Processor Percent Utilization Figure 4: Test 1 - Individual Processor Usage On the left of the chart, cpu0 and cpu1 show increasing utilization as Group 1 of simulated users reaches its peak. At the point the two additional processors are added, CPU utilization is initially low for each of the four CPUs, then begins to increase as Group 2 of simulated users begins its processing cycle. As this second group of simulated users completes its processing cycle, CPU utilization for all four processors begins to decrease. After the second group of simulated users finishes its processing cycle, two processors are removed from the LPAR, and CPU utilization for the remaining two processors increases briefly when the processors are removed, then begins to decrease as the first group of simulated user completes its processing cycle. Capacity on Demand: 2 – 4 Way Systems Dynamic LPAR Examples for SAP 11 :1 1 11 :01 :1 4 11 :01 :1 7 11 :01 :2 0 11 :01 :2 3 11 :01 :2 6 11 :01 :2 9 11 :01 :3 2 11 :01 :3 5 11 :01 :3 8 11 :01 :4 1 11 :01 :4 4 11 :01 :4 7 11 :01 :5 0 11 :01 :5 3 11 :01 :5 6 11 :01 :5 9 12 :01 :0 2 12 :01 :0 5 12 :01 :0 8 12 :01 :1 1: 01 Tim e Page 9 of 14 IBM Americas Advanced Technical Support Dynamic Memory Change 2000000 1950000 3,000 1900000 Memory Pages (available and used) 3,500 1850000 1800000 1750000 1700000 1650000 1600000 2,500 Dialog Steps Per Minute 2,000 Mem/Real/size Pages Used # Steps 1,500 1,000 500 1550000 1500000 0 Figure 5: Test 2 - Memory added to support additional workload Test 2 added memory and CPU to support an added workload. Figure 5 shows the impact of adding memory to the LPAR. The system used all available memory running the initial workload, starting at 11:39. Additional memory was added at 11:48 to support more users. As the number of users (and hence dialog steps per minute) increases, the number of memory pages used increases. When the additional users finish processing, the number of pages then drops. This test was run in a two-tier configuration, with SAP and DB2 running on a single system. In this configuration, the fixed demand for memory (DB2 and SAP instance) was large, and the variable demand for memory (additional SAP EM) was small. Capacity on Demand: 2 – 4 Way Systems Dynamic LPAR Examples for SAP 11 :3 9 11 :4 1 11 :4 3 11 :4 5 11 :4 7 11 :4 9 11 :5 1 11 :5 3 11 :5 5 11 :5 7 11 :5 9 12 :0 1 12 :0 3 12 :0 5 12 :0 7 12 :0 9 12 :1 1 12 :1 3 12 :1 5 Time Page 10 of 14 IBM Americas Advanced Technical Support 9. Conclusions: Our results with this test workload indicate that dynamic modification of the number of engines and the amount of memory can enable workload scalability in the LPAR. By extension, these results also illustrate the potential value that these dynamic resource allocations can have in production environments. By employing these tools for managing processors and memory to address changing workloads, companies can more effectively manage their computing environment with potentially fewer resources overall, and thus with corresponding savings. While the potential benefits are apparent, it is also important to appreciate that each customer’s environment, service level agreements, and workload will be different, and the actual benefit will be correspondingly different as well. The ability to easily change resource allocations for specific intervals to address changing workloads suggests that overall sizings can reflect both targeted peak workloads as well as normal workloads, and companies can balance their overall hardware requirements in combination with their service levels to determine an optimal architecture. Capacity on Demand: 2 – 4 Way Systems Dynamic LPAR Examples for SAP Page 11 of 14 IBM Americas Advanced Technical Support 10. Appendix A – Dynamic CPU Reconfiguration: Figure 6: WebSM screen for changing CPU allocation Figure 6 is a sample of the screen for moving processors between LPARs. Capacity on Demand: 2 – 4 Way Systems Dynamic LPAR Examples for SAP Page 12 of 14 IBM Americas Advanced Technical Support 11. Appendix A – Dynamic Memory Reconfiguration: Figure 7: WebSM screen for moving memory between LPARs Figure 7 is a sample of the screen for moving memory between LPARs. Capacity on Demand: 2 – 4 Way Systems Dynamic LPAR Examples for SAP Page 13 of 14 IBM Americas Advanced Technical Support Figure 1: Test 1 - Processors Available and Used .................................................................................................. 6 Figure 2: Test 1 - Dialog Step Scaling.................................................................................................................... 7 Figure 3: Test 1 - CPU Usage and Response Time ................................................................................................ 8 Figure 4: Test 1 - Individual Processor Usage........................................................................................................ 9 Figure 5: Test 2 - Memory added to support additional workload ....................................................................... 10 Figure 6: WebSM screen for changing CPU allocation........................................................................................ 12 Figure 7: WebSM screen for moving memory between LPARs .......................................................................... 13 Capacity on Demand: 2 – 4 Way Systems Dynamic LPAR Examples for SAP Page 14 of 14