Vblock Solution for SAP: Use Case and Performance Results - VCE

IntroductionLarge multifaceted data center organizations are under increasing pressure to reduce operating andcapital costs through virtualization technologies while also being asked to improve applicationavailability and performance. Vblock Systems provide administrators and architects the capability tonot only virtualize business-critical and resource-intensive applications such as SAP, but alsorecognize return on investment through improved performance and efficiency.This document addresses how SAP can be virtualized on Vblock Systems to achieve significantimprovements in application performance compared with a typical retail customer environment usingCisco network infrastructure, EMC storage and information infrastructure, and VMware virtualizationtechnologies. This document also provides test data and results illustrating the differences betweenSAP performance in non-virtualized and virtualized environments.Within this document, test data and results demonstrate the significant performance improvementsrealized with Vblock Systems. Performance analysis of these results is also given, to provide contextto what the results actually mean in production and test environments.Business caseEnterprise organizations need to validate the feasibility of virtualizing mission-critical applications likeSAP in their data center environments as part of an overall private cloud strategy. To address theirconcerns about virtualizing SAP and placing it into the private cloud, administrators must haveassurances that application performance and operation will in fact provide significant improvements.By adopting a private cloud strategy and virtualizing SAP on Vblock Systems, customers can achievekey business objectives to reduce costs through virtualization while also significantly improvingapplication performance through ease of use.About this documentThis document presents information on the performance of SAP on Vblock Systems in a virtualizedenvironment, compared to a retail customer’s production and test environment in a non-virtualizedenvironment.The test configuration was designed to support SAP running six application servers with close to20,000 SAPS on the Database Server and close to 9,000 SAPS on each application server in thenon-virtualized environment. Then, we ran a performance comparison between this configuration andthe Vblock System.This document describes how SAP is virtualized using Vblock Systems, and it includes several testscenarios with performance metrics and comparisons that demonstrate the benefits of SAP on VblockSystems. In addition, this document describes a set of use cases that are available when SAP isdeployed within a private cloud infrastructure.© 2013 VCE Company, LLC. All Rights Reserved.5

The purpose of this document is to describe how the:§ SAP solution was migrated to an offsite Vblock System.§ New environment was configured, tested, and validated to exceed the performance of a legacyenvironment.§ Advanced functionality of the Vblock System was used in value-add use cases, and validatedwithin a performance-testing environment.ScopeThis document provides a focused evaluation of the SAP landscape on Vblock Systems and isapplicable to a wide variety of SAP landscapes that could be virtualized to take advantage of theenhanced functionality of the Vblock System.AudienceThis document was written for customers interested in learning about SAP on the Vblock Systems,which includes SAP and infrastructure administrators and architects, as well as other individualstasked with evaluating, acquiring, managing, operating, or deploying SAP in a virtualized data centerenvironment.Key resultsThe following list details the key improvements observed during SAP on Vblock Systems testing:§ Performance improvement of 50% or more when running SAP on Vblock Systems comparedwith a retail customer’s production and test environments.§ Reduced complexity when configuring and deploying SAP, unlike physical server and databaseenvironments, which can be hampered by capacity, storage, and compute resource limitations.§ Increased scalability to dynamically add resources to a running virtual SAP dialog instance.§ Ability to perform SAP recovery using RecoverPoint continuous remote replication.§ Support for Stateless Computing, allowing Vblock Systems service profiles to be migratedacross the environment without negatively impacting running systems.§ Simplified provisioning of new SAP servers through orchestration and automationFeedbackTo suggest documentation changes and provide feedback on this paper, send email todocfeedback@vce.com. Include the title of this paper, the name of the topic to which your commentapplies, and your feedback.© 2013 VCE Company, LLC. All Rights Reserved.6

Technology overviewThis section summarizes the technologies used in the solution.Vblock SystemsThe Vblock System from VCE is the world's most advanced converged infrastructure—one thatoptimizes infrastructure, lowers costs, secures the environment, simplifies management, speedsdeployment, and promotes innovation. The Vblock System is designed as one architecture that spansthe entire portfolio, includes best-in-class components, offers a single point of contact from initiationthrough support, and provides the industry's most robust range of configurations.Vblock System 720The Vblock System 720 is an enterprise, service provider class mission-critical system in the VblockSystem 700 family, for the most demanding IT environments—supporting enterprise workloads andSLAs that run thousands of virtual machines and virtual desktops. It is architecturally designed to bemodular, providing flexibility and choice of configurations based on demanding workloads. Theseworkloads include business-critical enterprise resource planning (ERP), customer relationshipmanagement (CRM), and database, messaging, and collaboration services. The Vblock System 720leverages the industry’s best director-class fabric switch, the most advanced fabric based bladeserver, and the most trusted storage platform. The Vblock System 720 delivers greater configurationchoices, 2X performance and scale from prior generations, flexible storage options, denser compute,five 9s of availability, and converged network and support for a new virtualization platform thataccelerates time to service and reduces operations costs.Vblock System 320The Vblock System 320 is an enterprise and service provider ready system in the Vblock System 300family, designed to address a wide spectrum of virtual machines, users, and applications. It is ideallysuited to achieve the scale required in both private and public cloud environments. The VblockSystem 320 has been engineered for greater scalability and performance to support large enterprisedeployments of mission-critical applications, cloud services, VDI, mixed workloads and applicationdevelopment and testing. The Vblock System 320 delivers greater configuration choices, 2Xperformance and scale from prior generations, flexible storage options, denser compute, five 9s ofavailability, and converged network and support for a new virtualization platform that accelerates timeto service and reduces operations costs. Every Vblock System 320 is available with the marketleadingEMC VNX storage arrays.For more information, go to www.vce.com.© 2013 VCE Company, LLC. All Rights Reserved.7

Vblock Systems benefitsVblock Systems provide SAP customers with several benefits from its integrated hardware stackincluding:§ Fewer unplanned downtimes and reduced planned downtimes for maintenance activities§ Reduced complexity due to preconfigured and centralized IT resources leading to standardizedIT services§ Predictable performance and operational characteristics§ Tested and validated solutions with unified support and end-to-end vendor accountability§ Graceful scaling of a Vblock Systems environment by adding:- capacity to an existing Vblock System- more Vblock Systems§ Virtualized efficiency with predictable scaling for a given footprint© 2013 VCE Company, LLC. All Rights Reserved.8

Architecture overviewVblock System configurationThe table below describes the Vblock System 700 configuration used for this testing.ComponentCisco Unified ComputingSystemStorageStorage area networkConfiguration1 x Cisco B250 BladeMicrosoft Windows Server 2003 x64Microsoft SQL Server 2005 Enterprise Edition SP3 CU44 x Cisco B200 Blades – VMware vSphere ServersSAP central instance and SAP dialog instances on virtual machinesEMC Symmetrix VMAXCisco MDS 9222i SwitchesSAP server configurationThis section covers specific configuration information for the SAP server. The key point to note here isthat only the database server was physical; the rest of the servers were configured as virtual serverswithin the Vblock System. The table below describes the SAP server configuration.© 2013 VCE Company, LLC. All Rights Reserved.9

ComponentDatabase server (B250 Blade)running on physical hardwareStorageApplication servers – running onVMware vSphere (B200 Blades)SAP application serverVMware vSphere 4StorageConfiguration12 CPU cores (2 x six-core Westmere X5670 2.93 GHz)192 GB RAM22 x 320 GB data volumes8 x 30 GB temp DB volumes1 x 200 GB logs volume1 x 2 TB backup/restore volume1 x 50 GB SAP executables volume1 x 350 GB OS, SQL and pagefile volume1 x 25 GB clustered SQL main mount point volumeQuest LightSpeed used for backup/restore8 CPU cores (2 x quad-core Nehalem X5570 2.93 GHz) per blade96 GB RAM per blade4x4 vServer 40 GB RAM3x6 vServer 40 GB RAM25 GB boot volume100 GB host volumeThis section describes the high-level configuration of the SAP environment on the Vblock System. TheProduction/QA/Test/Dev SAP environments were virtualized and resided on the Cisco UCS. EMCSymmetrix VMAX provided tiered storage based on performance expectations through a SANnetwork to the SAP landscape.SAP production environment instance on Vblock SystemsThe configuration team was able to realize a key benefit of the Vblock System: the ability to supportmultitier architectures running either physical, virtual, or mixed modes.To demonstrate this capability, a Microsoft SQL Server was installed and configured for a retailcustomer’s SAP production environment system on a physical host. Using four ESXi hosts, eightvirtual machines were then created using five UCS servers to build the SAP landscape. The primarycomponents of the SAP landscape were:§ 1 x SAP central instance§ 7 x SAP application servers© 2013 VCE Company, LLC. All Rights Reserved.10

Figure 1 shows the SAP landscape running on a Vblock System 700 configuration at the virtual,physical, and storage layers.Figure 1. SAP landscape running on a Vblock System 700 configurationNote: Microsoft SQL Server 2005 is installed on a physical host while SAP central instance and dialog instancesare installed on virtualized hosts. The back-end storage used for this setup is EMC Symmetric VMAX.LayerVirtualPhysicalStorageDescription4 Cisco UCS B200 half-blade servers8-core CPU and 96 GB RAMMicrosoft SQL Server Database1 Cisco UCS B250-M2 full-blade server equipped with a 12-core CPU and192 GB RAM.Redundant pair of Cisco UCS 6120 Fabric Interconnects with 10 GigabitEthernet and Fibre Channel over Ethernet (FCoE) functionality.Cisco MDS 9222i Multiservice Modular Switch connects the UCS bladesthrough a fibre channel storage area network.© 2013 VCE Company, LLC. All Rights Reserved.11

Summary comparison of environmentsThe following table shows physical configurations of the retail customer’s production and testenvironments, compared with the Vblock System.Summary Customer production Customer test Vblock SystemDatabase server22 cores x 1.6 GHz(IA64/Itanium), 176 GB24 cores x 2.8 GHz(Opteron), 192 GB12 cores x 2.93 GHz(Nehalem/Westmere) 192GBDatabaseMicrosoft SQL Server2005Microsoft SQL Server 2005Microsoft SQL Server2005Operating systemMicrosoft WindowsServer 2003Microsoft Windows Server2003Microsoft WindowsServer 2003Central instance On App Server Tier On App Server Tier On App Server TierApp Server environment8 cores x 2.6 GHz(Opteron), 32 GB each8 cores x 2.4 GHz(Xeon)32 GB each4x4 vServer 40 GB RAM3x6 vServer 40 GB RAMApp Server number 6 6 HP Proliant BL680c G5 8Estimated SAPS on DBServerEstimated rating~19,388SAP 2-tier SD Benchmark:25,550Estimated rating: 22,675SAP 2-tier SDBenchmark : 25,500(approx.)Estimated SAPS on AppServer (each)9950 8775 6250HP LoadRunner N/A V 9.5 V 9.5Virtual users pergeneratorN/A 250(5 second frequency, 120runs)250(5 sec frequency, 120runs)Load Generators N/A 10 10The following definitions apply to each environment in this table:§ Customer production – the environment where the customer was actually running SAP. This canbe referred to as the “as-is” environment.§ Customer Test – the environment the customer was planning to implement after performancetesting was completed based on a new vendor platform. A copy of the existing productionenvironment was used. This can be referred to as the “to be” environment.§ Vblock System – the Vblock System used to measure performance against the Testenvironment at the customer site.© 2013 VCE Company, LLC. All Rights Reserved.12

Testing methodology and resultsHP LoadRunner performance testing landscapeThe LoadRunner environment was set up on the Vblock System providing direct access to the SAPapplication.Figure 2 shows the SAP PE2 landscape on the Vblock System. According to the virtualizedapplication servers (also known as dialog instances), the number of servers, amount of memory, andnumber of processor cores assigned could vary from test run to test run. HP Performance Center andHP LoadRunner 9.5 tools were used to generate a load on the PE2 Vblock System. LoadRunner wasused to stress the PE2 Vblock System by executing OTC, RTC, and FICO business processes. Thistool was also used to perform data analysis.Business processes (implemented as scripts) were created with the Virtual User Generator(LoadRunner scripting tool), which was later imported into the controller (Performance Center) toexecute the test scenario outlined during the planning phase of the project.Figure 2. LoadRunner landscape for SAP on Vblock SystemNote: The above diagram shows the LoadRunner landscape using two virtualized blade servers running 11virtual machines. Of these virtual machines, one was configured as Load Controller and 10 were used asLoad Generators.© 2013 VCE Company, LLC. All Rights Reserved.13

Testing overviewThe Vblock Solution for SAP described in this document consisted of a virtualized SAP instance ona Vblock System. A number of tests were performed on the SAP database (SAP DB), centralinstance, and an application server configuration comparable to what would be seen in typicalproduction and test environments to demonstrate the significant performance improvements that canbe expected when running SAP on Vblock Systems. Performance results between a virtualized SAPon Vblock Systems and a non-virtualized SAP landscape are detailed in this document. Performancetesting was compared with performance test results from a typical test environment.The following tests were performed:§ SAP application server layer§ SAP application server sizing§ Online response times tests and batch throughput§ Stress tests using HP LoadRunner§ SAP batch and dialog load tests to test Vblock System capacity limits§ Server, storage, and network components§ Deployment and scaling of servers§ Dynamic resource allocation§ Migration of various componentsThe purpose of this testing was to demonstrate the following characteristics of SAP on VblockSystems:§ Meets or exceeds existing physical environment performance using Vblock Systems§ Analysis of the key attributes of the performance pertaining to the Vblock System design§ Demonstrate the efficiency of resource provisioning on Vblock SystemsMethodologyOnly Vblock System and SAP standard procedures and methods were used to attain the benchmarkresults. The test results provided in this document were gathered using various systems andapplication administration tools. Testing experts compared the performance of the Vblock System withwhat would be seen in a traditional customer environment and divided the testing into two majorareas:§ Application (SAP environment)§ Data center operations (Vblock System) environments, listed below© 2013 VCE Company, LLC. All Rights Reserved.14

SAP environment performance testingThe SAP environment performance testing included two test cases:§ HP LoadRunner for interactive performance testingHP LoadRunner was used to simulate Online Dialog user load on the SAP environment andAverage Transaction Response. Both were then measured for the duration of test§ Batch processingThe batch workload was reproduced, where possible. Additional batch and dialog instance loadtesting was conducted to significantly increase the workload on the system to identify capacitylimits. In addition to the analysis of the LoadRunner results, usage statistics were gathered at theinfrastructure levels during batch processing.Data center operations testingThe data center operation testing was limited to three major categories:§ Addition of resources to a running virtual SAP dialog instanceThe testing team demonstrated the ability to add resources, such as vCPU and vMemory, to arunning virtual SAP dialog instance. The team also successfully added vCPUs (up to eight) andmemory (up to 80 GB RAM) to a SAP dialog instance running on a virtual machine. The additionof vCPUs and memory required a restart of the virtual machine. When the SAP dialog instancewas restarted, the additional vCPU and memory were immediately apparent (in SAP transactionOS06).§ Migration of service profilesThe testing team demonstrated and validated the nature of stateless computing on a VblockSystem by migrating the Vblock System service profiles from one physical blade server toanother. The relevant use cases were:- Hardware migration- Hardware maintenance- Hardware upgrade- Recovery in the event of hardware failure§ Operational testingThe operation-level testing was completed to demonstrate the versatility of the Vblock Systemand summarize the flexibility and agility of Vblock Systems. These use cases included thefollowing operational tests:- Deployment and scaling of the SAP application- On-demand provisioning of resources- Systems monitoring and management including patches and routine maintenance© 2013 VCE Company, LLC. All Rights Reserved.15

Infrastructure metricsPerformance monitoring tools were an important part of the testing process; in both physical andvirtualized environments these tools played a critical role. Resources such as database, CPU,memory, storage, I/O, and other components needed to be measured to ensure performancerequirements were met. For testing, the following performance monitoring tools were used to measureperformance:ServerThe following performance monitoring tools were used during the RTC, OTC and FICO runs tomeasure database performance and CPU usage:§ Physical server – PerfMon:PerfMon is an SNMP-based performance tool that was used to measure database and CPUperformance and usage while a series of SAP RTC, OTC, and FICO tests were executed on theVblock System.§ Virtual server – VMware vCenter Performance Charts and ESXTOPThe performance counters maintained by vCenter and accessed via the vCenter client wereused to monitor the performance of the virtualized customer environment. Alternatively,VMware’s ESXTOP was executed on the ESXi server to provide realtime views of ESXi serverand virtual machine performance.Storage I/OStorage and I/O performance were measured using the EMC Symmetrix VMAX STP tool. STP can beused as a workload analyzer to collect performance statistics on a Symmetrix VMAX storage array. Inthe case of this testing, STP was used to measure storage performance while RTC, OTC and FICOruns were executed on the Vblock System.VMware vCenterVMware vCenter was used to take advantage of the capability to view CPU, memory, disk, andnetwork resources in a single performance chart, rather than having to navigate multiple charts.Specifically, these charts provided:§ Aggregated views and high-level summaries of resource distribution across the entireenvironment§ Thumbnail views of virtual machines, hosts, resource pools, clusters, and data stores§ Drill-down capability to perform root cause analysis of problems§ Detailed storage views showing usage by file typeSolarWindsSolarWinds was used to measure network and fabric-level performance of the Vblock System.© 2013 VCE Company, LLC. All Rights Reserved.16

Performance comparison and usageThis section of the report contains a comparison of the performance and usage of infrastructureresources while the environment was subjected to three critical business processes:§ RTC§ OTC§ FICONote: The RTC, OTC, and FICO performance results were based on workload-generating scripts provided bythe customer to measure the business process performance of the Vblock System compared with thecustomer test environment.This section covers two major areas:§ A summary of the business process performance§ Details of the underlying resource usage from an infrastructure perspectiveThe following three tests were run on the Vblock System:§ RTC run§ OTC run with a 3x6 virtual machine configuration§ FICO run with a 3x6 virtual machine configurationFor each of the above runs, application, vSphere servers and storage-level performance comparisonswere performed, along with resource usage.© 2013 VCE Company, LLC. All Rights Reserved.17

RTC runThe table below shows performance statistics.SAP RTC transactionsCustomersystem Vblock System DifferenceSAPGUI_IDOC_17_VAR1_RTC_EXECUTE 148.557 77.047 48%SAPGUI_IDOC_17_VAR2_RTC_EXECUTE 139.516 66.139 53%SAPGUI_IDOC_338_VAR1_RTC_EXECUTE 762.415 284.458 63%SAPGUI_IDOC_338_VAR2_EXECUTE 697.899 266.804 62%SAPGUI_MB51_RTC_EXECUTE 2.463 1.491 39%SAPGUI_ZPTR_MAIN_RTC_EXECUTE 0.534 0.297 44%SAPGUI_ZPTR_VAR1_RTC_EXECUTE 103.19 71.192 31%1854.574 767.428 59%Figure 3. Performance statisticsNote: The figure above shows the comparison of performance response time between the Vblock System andthe customer’s test platform. Results show that the Vblock System was able to process seven businesscriticalRTC transactions with an improved average response time of 59%.© 2013 VCE Company, LLC. All Rights Reserved.18

FICO runApplication performance comparisonThe table and Figure 4 illustrate the performance improvements seen when running SAP FICOtransactions in the Vblock System environment, as compared with the customer environment.SAP FICO transactionsCustomersystem Vblock System DifferenceSAPGUI_FAGLB03_FICO_EXECUTE 23.348 0.178 99%SAPGUI_FAGLL03_FICO_EXECUTE 292.46 172.764 41%SAPGUI_FBL1N_FICO_EXECUTE 14.132 7.694 46%SAPGUI_FBL5N_FICO_EXECUTE 103.185 45.744 56%SAPGUI_KE24_FICO_EXECUTE 20.555 9.611 53%SAPGUI_KE30_VAR1_FICO_EXECUTE 34.28 15.703 54%SAPGUI_KE30_VAR2_FICO_EXECUTE 423.162 133.011 69%SAPGUI_ZGRIRAGING_FICO_EXECUTE 1058.521 189.728 82%SAPGUI_ZPOACCRUAL_FICO_EXECUTE 1163.213 307.942 74%3132.856 882.375 72%Figure 4. SAP FICO transactions running on three virtual application servers© 2013 VCE Company, LLC. All Rights Reserved.19

Note: The figure above shows the comparison of performance response time between the Vblock System andthe customer’s test platform. Results show that the Vblock System was able to process nine businesscriticalFICO transactions with an improved average response time of 72%.OTC runApplication performance comparisonThe table below and Figure 5 illustrate the performance improvements seen when running SAP OTCtransactions in the Vblock System, as compared with the customer environment.SAP OTC transactionsCustomersystemVblockSystemDifferenceSAPGUI_VA41_OTC_DATA_EXECUTE 0.1 0.139 -39%SAPGUI_VKM1_VAR2_OTC_EXECUTE 59.298 21.447 64%SAPGUI_VKM1_VAR3_OTC_EXECUTE 51.823 19.315 63%SAPGUI_ZBACKORDER_VAR1_OTC_EXECUTE 0.288 0.1 65%SAPGUI_ZBACKORDER_VAR2_OTC_EXECUTE 0.414 0.1 76%SAPGUI_ZDLVSTATUS_OTC_EXECUTE 16.412 18.083 -10%SAPGUI_ZNOBACKORDER_OTC_EXECUTE 147.907 111.665 25%SAPGUI_ZVA14L_OTC_EXECUTE 8.472 1.083 87%SAPGUI_ZVASSUMM_VAR1_OTC_EXECUTE 26.027 11.733 55%SAPGUI_ZVASSUMM_VAR2_OTC_EXECUTE 1.538 0.497 68%SAPGUI_ZVENDORMARK_OTC_EXECUTE 2.68 0.906 66%SAPGUI_ZWORKLOAD_MAIN_EXECUTE 30.984 16.493 47%SAPGUI_ZWORKLOAD_VAR1_OTC_EXECUTE 34.455 15.443 55%SAPGUI_ZWORKLOAD_VAR2_OTC_EXECUTE 44.526 14.168 68%424.924 231.172 46%© 2013 VCE Company, LLC. All Rights Reserved.20

Figure 5. SAP OTC transactions running on three virtual appliccation serversNote: The figure above shows the comparison of performance response time between the Vblock System andthe customer’s test platform. Results show that the Vblock System was able to process 14 businesscriticalOTC transactions with an improved average response time of 46%.Performance comparisonThe performance comparison was completed for application, vSphere server, and storagecomponents from the application performance availability and usage perspectives:Resource usageResource usage focus was on the Vblock System at the component level. The resource usage wascaptured to understand the overall performance of the Vblock System from an infrastructureperspective, while running SAP as one of the solutions. The test team was interested in the use of thefollowing key components of the Vblock System while running SAP:§ Network§ Storage§ Servers§ CPU© 2013 VCE Company, LLC. All Rights Reserved.21

From the virtual machines perspective, the four application servers (4 x vCPU virtual machines) usedwere:§ SAPCL55§ SAPCL53§ SAPCL54§ SAPCL59Performance analysis and key contributorsThe significant performance metrics and measurements described in the previous section can berealized due to a number of improvements in storage and application layout, network optimization,and inherent advantages of the Vblock System, with its optimized multi-application compute system.The following key factors contributed to the superior performance improvements observed in the testresults provided in this configuration report.Processor architecture and configurationThe Xeon 5570 processor was shown in testing to exceed the performance of the Opteron processorin server benchmark testing (1.6 times faster); while the Xeon 5680 (used in these tests) wasobserved to far exceed the 5570’s performance by an additional 43%, leading the combination of theXeon 5680 and UCS B250 server to vastly outperform Opteron-based HP servers.Figure 6. Cisco UCS B250 M2 performance© 2013 VCE Company, LLC. All Rights Reserved.22

UCS integrated and converged fabric configurationOne of the key factors in understanding how these performance results exceeded expected results isin the UCS blade configuration. Because the SAP layout enables the database server (physical), allapplication servers (virtual), and LoadRunner clients (virtual) to reside on a single chassis connectedto a set of 6120 Fabric Interconnects, the majority of SAP traffic remains internal, thus takingadvantage of the large amount of bandwidth available.Virtual application server dynamic performance tuningApplication server virtual machines in the Vblock System were sized and numbered to approximatelymatch the SAPS capacity of the TE2 application tier, which was 3 x 8,775 (approximately 26,325)SAPS.In vSphere, four- way application servers are a “sweet spot” and the SAPS rating of a four-way virtualmachine is estimated to be 6,250. Based on 6,250 SAPS per four-way virtual machine, fourapplication servers were required to approximately match the TE2 application tier rating. After initialtesting with a 4 x 4 application server virtual machines configuration, an uneven distribution in theCPU usage was observed, whereby 1-2 of the virtual machines were at 100% CPU usage, while theremaining virtual machines were relatively underused. This was attributed to imperfect load balancingof the virtual users as they were ramped up by LoadRunner.To more evenly distribute CPU usage across the application tier and prevent a virtual machine fromspiking to 100%, the number of virtual machines was reduced and then made larger in size. The nextsizing configuration to reflect this and also roughly match the TE2 application tier SAPS rating was 3 x6-way virtual machines. The SAPS rating of a 6-way virtual machines configuration is approximatelybetween 8,000 and 9,000 SAPS (estimated from 4- and 8-way benchmark certifications 2009028 and2009029, which shows approximately linear scalability).Optimization and balancing of compute, network, and storage throughout the Vblock SystemPerformance testing showed that less than 25% of cache, disk, and front-end and back-end portswere used. The Symmetrix VMAX storage array can handle much larger workloads, thus validating akey design point of optimization and balancing of compute, network and storage throughout theVblock System. In this example, a Vblock System 700 minimum configuration was designed with fourUCS chassis with corresponding network and storage capacity. The customer test bed consumes oneUCS chassis, and thus less than 25% of storage resources.© 2013 VCE Company, LLC. All Rights Reserved.23

SAP on Vblock System use casesThis paper provides the following use case descriptions:§ Deployment and scaling of servers [vCPU, vMemory]§ SAP recovery using EMC RecoverPoint continuous remote replication (CRR)§ Stateless computing : Migration of Vblock System service profiles§ Dynamic on-demand provisioningDeployment and scaling of servers (vCPU, vMemory)The testing team demonstrated the ability to add resources, such as vCPU and vMemory, to a runningvirtual SAP dialog instance.The team successfully added vCPUs (up to eight) and memory (up to 80 GB RAM) to an SAP dialoginstance running on a virtual machine. The addition of vCPUs and memory required restarting thevirtual machine. Once the SAP dialog instance was restarted, the additional vCPU and memory wereimmediately apparent (in SAP transaction OS06).Application server virtual machines in the Vblock System were sized and numbered to approximatelymatch the SAPS capacity of the customer. The TE2 application tier was 3 x 8,775 (approximately26,325) SAPS. When using vSphere, four-way application servers were considered to be the sweetspot: The SAPS rating of a four-way virtual machine is estimated at 6,250 (source: SD benchmarkcertification 2009028). Based on 6,250 SAPS per four-way virtual machine, the team required four ofthese to approximately match the TE2 application tier rating. After initial testing with 4 x 4 applicationserver virtual machines, the team observed an uneven distribution in the CPU usage where one ortwo of the machines were at 100% vCPU while the remaining were relatively underused. The teamattributed this to imperfect load balancing of the virtual users by LoadRunner.To distribute vCPU usage more evenly across the application tier, and also to prevent any virtualmachine from spiking to 100%, the team reduced the number of virtual machines but made themlarger. The next appropriate sizing configuration (which also approximates the TE2 application tierSAPS rating) was 3 x 6-way virtual machines. The SAPS rating of a 6-way virtual machine wasapproximately between 8,000 and 9,000 SAPS (estimated from 4- and 8-way benchmark certifications2009028 and 2009029, which show approximately linear scalability).The following data was obtained from ESXTOP, with the data captured as a batch file and viewed inESXplot (freeware from www.virtualizetips.com/2010/03/how-to-use-esxplot-to-read-your-esxtopreports/).The metric shown below is the percentage (%) used of the virtual machine. As each virtualmachine is 4 x vCPU, the percentage used needs to be divided by 4 (see the following link forexplanation http://communities.vmware.com/docs/DOC-9279, section “%USED”).© 2013 VCE Company, LLC. All Rights Reserved.24

Figure 7. SAPCL55 application server virtual machine performance (CPU %used)© 2013 VCE Company, LLC. All Rights Reserved.25

Figure 8. SAPCL53 application server virtual machine performance (CPU% used)© 2013 VCE Company, LLC. All Rights Reserved.26

Figure 9. SAPCL54 application server virtual machine performance (CPU% used)© 2013 VCE Company, LLC. All Rights Reserved.27

Figure 10. SAPCL59 application server virtual machine performance (CPU% used)© 2013 VCE Company, LLC. All Rights Reserved.28

SAP recovery using EMC RecoverPoint CRRIf you need to install a software update, apply a patch, or perform testing on your SAP productiondata, you should capture a “point in time” when you know that the data is accurate using EMCRecoverPoint, which allows continuous data protection, either locally or remotely through the use ofbookmarks.EMC RecoverPoint continuous data protection technology allows you to perform the following actionsin an SAP environment:§ Provide local protection (CDP)§ Provide remote replication (CRR)§ Provide protection for any point in time§ Present any point in time to another host in the SAP environmentFor this testing, RecoverPoint CRR was set up in a heterogeneous storage environment. Replicationwas performed from a Vblock System 700 to a Vblock 1, and the configuration used array-basedsplitter technology on the CLARiiON storage of the Vblock System and SANTap-based splittertechnology on the VMAX storage of the Vblock System 700. Heterogeneous replication was thenperformed on the boot LUN and remaining SAP LUNs.The boot LUN was replicated from the primary UCS to the disaster recovery (DR) UCS. The systemwas fully booted at the disaster recovery site without affecting the primary (production) site, as shownin Figure 11.Figure 11. Customer SAP Boot running on RPA 1© 2013 VCE Company, LLC. All Rights Reserved.29

Performing recovery using RecoverPoint bookmarksYou can view and manage your SAP environment through the RecoverPoint GUI, and protect theenvironment based on individual LUNs or groups of LUNs. Using RecoverPoint bookmarks, you cancreate reference points in the indefinitely granular landscape of point-in-time protection, which you canuse to perform a production rollback, if necessary.Creating a RecoverPoint bookmark1. In the RecoverPoint GUI, click the Bookmark link. The Create a bookmark image for SAPSolutions Manager page appears.2. Enter a name for the bookmark in the Bookmark Name field and click OK.To enable image access:1. In the Recovery GUI, click the arrow icon and select Enable Image Access on the recovery host.An Enable Image Access wizard appears, which allows you to transfer this bookmark image tothe recovery server.2. Select one of the following options to enable image access:a. Select the latest image, which selects the latest image savedb. Select an image from the list, which allows you to select from a list of saved imagesc. Specify a desired point in time, which allows you to select a specific point in time3. Select Groups from the RecoverPoint GUI menu and select Group Sets. This then allows you tocreate a new consistency group.Creating a new consistency group1. Click Create. A Group Set dialog appears.2. Select the consistency groups you want to group together for the new consistency group.3. Enter a name for the SAP consistency group and click OK.4. Select the frequency you want to use for bookmarks. Setting the frequency controls how oftenbookmarks will be created across your consistency groups and allows you to have granularity toroll back just one at a time, or present only one bookmark to the recovery server while stillmaintaining a common point in time across all three consistency groups in your SAP environment.© 2013 VCE Company, LLC. All Rights Reserved.30

Creating a suspend stateTo bring up consistency groups simultaneously, you need to put the production environment into aSuspend state to ensure there are no IP address conflicts. To put an SAP virtual machine in Suspendstate:1. In the RecoverPoint GUI, right-click SAP Solution Manager and select Suspend. The ConfirmSuspend dialog prompt appears.2. Click Yes to suspend the virtual machine.3. Once you initiate the Suspend state, you can enable access to the SAP bookmark that youcreated earlier. If there is data corruption or data integrity loss, this bookmark allows you to rollyour production data back to the point-in-time of the bookmark.4. Enable image access to the bookmark by selecting the Image Access icon and clicking EnableImage Access. The Enable Image Access window appears.5. Click Select image from the list and browse to the SAP Patch Installation bookmark.6. Click Next. The Image Access Mode window appears.7. Click Image Access Mode. There are two options for this selection: logged access and virtualaccess.a. Logged access takes the point-in-time and copies the data to the target LUNs.b. Virtual access allows for immediate access to the data through memory mappingtechnologies. You can also select the Roll image in background checkbox to also copy thedata to the target LUNs.Starting the virtual machineYou can also start the virtual machine to verify everything is operating properly by performing thefollowing steps:1. Verify that the SAP services are running in SAP Solutions Manager.2. On the desktop for the virtual machine, click the SAP Logon icon to log in to SAP.3. In the SAP Logon window, select Solution Manager to ensure that SAP is running properly.4. Return to the RecoverPoint GUI. Notice that there is a Recovery Options icon on the right thatallows you to select either of the following options:a. Failover to Recoveryb. Recover Production© 2013 VCE Company, LLC. All Rights Reserved.31

Stateless computingIn the Vblock System, SAP instances can be seamlessly migrated between UCS blades usingVMware’s vMotion technology. Moving SAP instances between blades allows administrators toschedule maintenance (for example, installing a SAP kernel update, OS updates or patches, or adatabase update/patch) on a blade while maintaining minimal production downtime. Redundancy canalso be enabled through the migration of SAP instances; ensuring that SAP production data is not lostin case of blade failure.Before moving a SAP instance from one blade to another, ensure that the following conditions aremet:§ SAP is running on a virtual machine on an ESXi Server.§ Both ESXi Servers:- Have compatible CPUs.- Are connected to a virtual switch assigned for vMotion.- Are connected to a production switch enabled for user access.§ SAP virtual disk and VMFS configuration files reside on shared storage connected to both ESXihosts.Moving a SAP instance from one UCS blade to another1. Open the Virtual Infrastructure Client application and locate the SAP instance you want to move(for example, sap_vm).2. Right-click the SAP instance and click Migrate. A list of destination hosts is displayed where youcan move the SAP instance.3. Select the host you want to use to move the SAP instance and click Next. A Resource Poolspage is shown.4. Select the resource pool you want to use and click Next. A Migration Policy page appears.5. Choose the priority of the migration. There are two options:a. High Priority - ensures virtual machine availability during migration by reserving resourceson both source and destination hosts.b. Low Priority - resources are NOT reserved; thus, the virtual machine may becomeunavailable during migration.6. Click Next. A Summary page is displayed. Verify that the information is correct and click Finish.The progress of the migration is shown in the Virtual Infrastructure Client window (bottompane).7. After the migration completes, verify that the SAP instance is running on the destination host.© 2013 VCE Company, LLC. All Rights Reserved.32

Dynamic on-demand provisioningProvisioning new SAP servers on the Vblock System can be simplified through the use of automation.Using customized scripts and UIM, SAP servers can be more easily managed and provisionedwithout requiring significant configuration and setup steps. This approach can be particularly useful forservice providers where a rapid, error-free, and standardized approach is required.© 2013 VCE Company, LLC. All Rights Reserved.33

ConclusionThis paper demonstrates the operational and performance improvements that can be realized whendeploying SAP on a Vblock System in a large-scale production environment. The testingdemonstrates that an SAP instance can be rapidly configured and deployed, unlike physical serversand databases, which are hampered by limitations of capacity, storage, and compute resources. Thetest team was able to configure and deploy Vblock System storage, compute, and virtualizationcapabilities with advanced system administration technologies. Various infrastructure changes wererequired throughout this exercise, allowing administrators and architects to dynamically adjustcapacity, storage, and processing capabilities. Some of these benefits are documented in the usecases.The SAP on Vblock Systems defined in this document was designed to mirror a retail customer’sexisting production and test environments to illustrate the significant performance improvementsobserved when SAP was deployed on the Vblock System. A series of customer-provided dialog andbatch workload-generating scripts (RTC, OTC, and FICO) runs were performed. Performancestatistics were collected and results analyzed that provided a compelling comparison against resultsseen in a customer’s non-optimized environment.The performance metrics and measurements contained in this report were achieved due to a numberof storage optimizations and application layout, network, and inherent advantages of the VblockSystem, with its optimized multi-application compute system. Within the test Vblock System, one UCSchassis (8 blades) was comparable to the customer’s entire SAP production farm, and averaged aperformance improvement of 50%.© 2013 VCE Company, LLC. All Rights Reserved.34

Appendix A: Performance and comparison resultsRTC runThe team chose to cover RTC to explain the rationale behind the better performance and efficientresource usage of SAP on a Vblock System.Application performanceFrom an application performance perspective, RTC was run with in 4x4 virtual server layers andcontained four application servers, each configured with 4 vCPU.RTC run 4x4The following table shows the performance difference between SAP within the customer environmentand SAP on Vblock Systems while running identical RTC scripts through HP LoadRunner. SAP on theVblock System performed 59% better. The performance statistics are presented in the following tableand Figure 12.SAP RTC transactionsCustomer systemVblockSystemDifferenceSAPGUI_IDOC_17_VAR1_RTC_EXECUTE 148.557 77.047 48%SAPGUI_IDOC_17_VAR2_RTC_EXECUTE 139.516 66.139 53%SAPGUI_IDOC_338_VAR1_RTC_EXECUTE 762.415 284.458 63%SAPGUI_IDOC_338_VAR2_EXECUTE 697.899 266.804 62%SAPGUI_MB51_RTC_EXECUTE 2.463 1.491 39%SAPGUI_ZPTR_MAIN_RTC_EXECUTE 0.534 0.297 44%SAPGUI_ZPTR_VAR1_RTC_EXECUTE 103.19 71.192 31%1854.574 767.428 59%© 2013 VCE Company, LLC. All Rights Reserved.35

Figure 12. RTC performance statisticsNote: The figure above shows the comparison of response times between the Vblock System and thecustomer’s test platform. Results show that the Vblock System was able to process seven business criticalRTC batch jobs with an improved average response time of 59%.Resource usageAs shown above, the RTC run was 59% better; however, resource level usage has been remarkablybetter. While there was no benchmark or comparison data available from the customer, it can bestated that a duplicate customer SAP implementation could be run. This fact is clear based on VblockSystem resource usage.Network usageIn a distributed environment, the major bottleneck among application, database, and client is oftendetermined to be the network. In the Vblock System, all SAP environment components reside in thesame box, creating a “super-highway” of sorts that allows each component to communicate moreefficiently.© 2013 VCE Company, LLC. All Rights Reserved.36

I/O usageFigures 13 and 14 show the I/O usage for the two fibre channel connections (fc2/1 and fc2/2) from the6120 Fabric Interconnect connected to the MDS, which connects to the Symmetrix VMAX storagearray. Each fibre channel interface is capable of handling up to 4 Gbps of throughput. For this run,each interface is only using approximately 25 Mbps and 30 Mbps at peak intervals during the initialramp-up of the LR run. There is plenty of link capacity to spare as the usage is under 10% used attheir highest point.FCoE usage from chassis to fabric interconnect was also observed during the RTC run and isillustrated in the charts displayed below.Figure 13. I/O usage for fabric interconnect interfaces to MDS for fc2/1© 2013 VCE Company, LLC. All Rights Reserved.37

Figure 14. I/O usage for fabric interconnect interfaces to MDS for fc2/2FCoE usageFigures 15 and 16 show the aggregate FCoE usage for the two most highly used FCoE 10 Gbpsinterfaces (eth1/1 and eth1/6) from the 6120 Fabric Interconnect connected southbound to the I/Omodules for each server in the UCS chassis. For this RTC run, each interface is only usingapproximately 25 Mbps and 40 Mbps at peak intervals during the initial ramp up of the LR run, thus,as can be seen, there is plenty of link capacity to spare as the usage is under 10% used at theirhighest point.© 2013 VCE Company, LLC. All Rights Reserved.38

Figure 15. FCoE usage from chassis to fabric interconnect for eth1/1Figure 16. FCoE usage from chassis to fabric interconnect for eth1/6© 2013 VCE Company, LLC. All Rights Reserved.39

CPU/vCPUThe vCPU performance is shown in Figure 17 using standard server performance monitoring tools (inthis case, PerfMon). The relationship between the vCPU and raw CPU can be understood by viewingthe raw performance and relating this performance to the virtual machine CPU allocations. The testteam did not observe a pegged vCPU; hence, the raw CPU statistics were not collected. The onlysituation in which CPU was pegged happened because unified load distribution was not enabledwithin the application layer.Figure 17 shows vCPU performance and Figure 18 shows the physical CPU performance. In the caseof a virtual machine with four CPUs, the y axis must be divided by 4 to understand the performance ofeach vCPU.Note: During the RTC run, the database server CPU usage is measured as a percentage, based on the verticalaxis numbers, thus indicating that the B250 M2 database server can handle a much more stringent load.Figure 17. vCPU performance© 2013 VCE Company, LLC. All Rights Reserved.40

Figure 18. SAP50 database server performance (CPU)StorageThere are four key metrics on a storage array that are of interest.§ Front-end fibre channel ports/CPU§ Cache (memory slots)§ Back-end directors CPU§ Disks (fibre channel)© 2013 VCE Company, LLC. All Rights Reserved.41

Figure 19. Front-end fibre channel ports/CPUNote: The SAP front-end fibre channel ports were less than 15% used (max) for the RTC run.© 2013 VCE Company, LLC. All Rights Reserved.42

Figure 20. Cache (memory slots)Note: Write pending count is data that is in a cache slot waiting to be written to disk. In this example, for the RTCrun, the write pending count (approx. 30,000) is much less than the write pending limits (650,000).© 2013 VCE Company, LLC. All Rights Reserved.43

Figure 21. Back end directors CPUNote: Back end directors were less than 20% used. These are the CPUs of the storage array that move the datafrom memory slots to disks.© 2013 VCE Company, LLC. All Rights Reserved.44

Figure 22. Disks (fibre channel)Note: This bar graph shows that although the disks percentage (%) max was used, the cache was under-used.There was no impact on the host, and host write response time was at memory speeds; not disk speeds.© 2013 VCE Company, LLC. All Rights Reserved.45

FICO runApplication performance comparisonThe following table and Figure 23 illustrate the performance improvements seen when running SAPFICO transactions in the Vblock System, as compared with the customer environment.SAP FICO transactions Customer system Vblock System DifferenceSAPGUI_FAGLB03_FICO_EXECUTE 23.348 0.178 99%SAPGUI_FAGLL03_FICO_EXECUTE 292.46 172.764 41%SAPGUI_FBL1N_FICO_EXECUTE 14.132 7.694 46%SAPGUI_FBL5N_FICO_EXECUTE 103.185 45.744 56%SAPGUI_KE24_FICO_EXECUTE 20.555 9.611 53%SAPGUI_KE30_VAR1_FICO_EXECUTE 34.28 15.703 54%SAPGUI_KE30_VAR2_FICO_EXECUTE 423.162 133.011 69%SAPGUI_ZGRIRAGING_FICO_EXECUTE 1058.521 189.728 82%SAPGUI_ZPOACCRUAL_FICO_EXECUTE 1163.213 307.942 74%3132.856 882.375 72%Figure 23. SAP FICO transactions running on three virtual application servers© 2013 VCE Company, LLC. All Rights Reserved.46

Note: The figure above shows the comparison of response time between the Vblock System and the customer’stest platform. Results show that the Vblock System was able to process nine business-critical FICOtransactions with an improved average response time of 72%.Resource usage for I/OFigures 24 and 25 show the I/O usage for the two Fiber Channel connections (fc2/1 and fc2/2) fromthe 6120 Fabric Interconnect connected to the MDS, which connects to the Symmetrix VMAX storagearray. Each fibre channel interface is capable of handling up to 4 Gbps of throughput. As you can see,for this FICO run, each interface is only using approximately 90 Mbps and 380 Mbps at peak intervalsduring the initial ramp-up of the LR run, leaving plenty of link capacity to spare as the usage is under10% used at their highest point.Figure 24. I/O usage for Fabric Interconnect interfaces to MDS for fc2/1© 2013 VCE Company, LLC. All Rights Reserved.47

Figure 25. I/O usage for Fabric Interconnect interfaces to MDS for fc2/2Resource usage for FCoEFigures 26 and 27 show the aggregate FCoE usage for the two most highly used FCoE 10 Gbpsinterfaces (eth1/1 and eth1/6) from the 6120 Fabric Interconnect connected southbound to the I/Omodules for each server in the UCS chassis. For this FICO run, each interface is only usingapproximately 25 Mbps and 40 Mbps at peak intervals during the initial ramp-up of the LR run, thus,as can be seen, there is plenty of link capacity to spare, as the usage is under 10% used at theirhighest point.© 2013 VCE Company, LLC. All Rights Reserved.48

Figure 26. FCoE usage from chassis to Fabric Interconnect for eth1/1Figure 27. FCoE usage from chassis to Fabric Interconnect for eth1/8© 2013 VCE Company, LLC. All Rights Reserved.49

CPUIn Figure 28, the maximum CPU usage on App Server SAPCL53 on a Vblock System during theFICO run was measured at 27.02 % during a 2-hour period.Figure 28. CPU performanceDatabase performance was also measured using PerfMon to show the minimal impact on databaseperformance and usage while FICO tests were being run. Notice in Figure 29 how the maximumresource usage of the database was only 28.33 % at its peak.© 2013 VCE Company, LLC. All Rights Reserved.50

Figure 29. Database performanceStorageThere are four key metrics on a storage array that are of interest:§ Front-end (FE) fibre channel ports/CPU§ Cache (memory slots)§ Back-end directors CPU§ Disks (fibre channel)© 2013 VCE Company, LLC. All Rights Reserved.51

Figure 30. Front end fibre channel ports/CPUNote: The FICO run was the heaviest workload of the three runs. The directors were 65% used.Figure 31. Cache (memory slots)© 2013 VCE Company, LLC. All Rights Reserved.52

Note: Write pending count is data that is in a cache slot waiting to be written to disk. In this example, for theFICO run, the write pending count (approximately 11,000) is much less than the write pending limit(650,000).Figure 32. Back-end directors CPUNote: Back-end directors percentage was less than 15% usage. These are the CPUs of the storage array thatmove the data from memory slots to disks.© 2013 VCE Company, LLC. All Rights Reserved.53

Figure 33. Disks (fibre channel)Note: This bar graph shows that although the disk’s percentage (%) max was used, the cache was under-used.There was no impact on the host, and host write response time was at memory speeds; not disk speeds.In fact, the disk use percentage was less than 70%.© 2013 VCE Company, LLC. All Rights Reserved.54

OTC runApplication performance comparisonThe following table and Figure 34 illustrate the performance improvements seen when running SAPOTC transactions in the Vblock System, as compared with the customer environment.SAP OTC transactionsCustomersystemVblockSystemDifferenceSAPGUI_VA41_OTC_DATA_EXECUTE 0.1 0.139 -39%SAPGUI_VKM1_VAR2_OTC_EXECUTE 59.298 21.447 64%SAPGUI_VKM1_VAR3_OTC_EXECUTE 51.823 19.315 63%SAPGUI_ZBACKORDER_VAR1_OTC_EXECUTE 0.288 0.1 65%SAPGUI_ZBACKORDER_VAR2_OTC_EXECUTE 0.414 0.1 76%SAPGUI_ZDLVSTATUS_OTC_EXECUTE 16.412 18.083 -10%SAPGUI_ZNOBACKORDER_OTC_EXECUTE 147.907 111.665 25%SAPGUI_ZVA14L_OTC_EXECUTE 8.472 1.083 87%SAPGUI_ZVASSUMM_VAR1_OTC_EXECUTE 26.027 11.733 55%SAPGUI_ZVASSUMM_VAR2_OTC_EXECUTE 1.538 0.497 68%SAPGUI_ZVENDORMARK_OTC_EXECUTE 2.68 0.906 66%SAPGUI_ZWORKLOAD_MAIN_EXECUTE 30.984 16.493 47%SAPGUI_ZWORKLOAD_VAR1_OTC_EXECUTE 34.455 15.443 55%SAPGUI_ZWORKLOAD_VAR2_OTC_EXECUTE 44.526 14.168 68%424.924 231.172 46%© 2013 VCE Company, LLC. All Rights Reserved.55

Figure 34. SAP OTC transactions running on three virtual application serversNote: The figure above shows the comparison of response time between the Vblock System and the customer’stest platform. Results show that the Vblock System was able to process 14 business-critical OTCtransactions with an improved average response time of 46%.I/O resource usageFigures 35 and 36 show the I/O usage for the two fibre channel connections (fc2/1 and fc2/2) from the6120 Fabric Interconnect connected to the MDS, which connects to the Symmetrix VMAX storagearray. Each fibre channel interface is capable of handling up to 4Gbps of throughput. As can be seenin the graphs, for this OTC run, each interface is only using approximately 8Mbps and 10Mbps at aconsistent level during the LR run, leading to plenty of link capacity to spare, as the usage is under10%.© 2013 VCE Company, LLC. All Rights Reserved.56

Figure 35. I/O usage for fabric interconnect interfaces to MDS on fc2/1Figure 36. I/O usage for fabric interconnect interfaces to MDS on fc2/2© 2013 VCE Company, LLC. All Rights Reserved.57

FCoE resource usageFigures 37 and 38 show the aggregate FCoE usage for the two most highly used FCoE 10Gbpsinterfaces (eth1/1 and eth1/8) from the 6120 Fabric Interconnect connected southbound to the I/Omodules for each server in the UCS chassis. As can be seen in these graphs, for this FICO run, eachinterface is only using approximately 5-6Mbps at sustained levels during the LR run, leaving plenty oflink capacity to spare, as the usage is under 10%.Figure 37. FCoE usage from chassis to fabric interconnect on eth1/1© 2013 VCE Company, LLC. All Rights Reserved.58

Figure 38. FCoE usage from chassis to fabric interconnect on eth1/8vSphereRefer to the RTC run section to view vSphere performance and usage.CPU usageFigure 39 shows the CPU usage metrics for the SAPCL54 App Server when an OTC run is executedfrom 2:39 pm to 3:39 pm. Notice that the maximum CPU usage during this one-hour period was8.78%, with an average CPU usage of 1.2%.© 2013 VCE Company, LLC. All Rights Reserved.59

Figure 39. CPU usage metricsDatabase performance was also measured using PerfMon to show the minimal impact on databaseperformance and usage while FICO tests were being run. Figure 40 shows how the maximumresource usage of the database was only 28.33% at its peak.© 2013 VCE Company, LLC. All Rights Reserved.60

Figure 40. Database performance measurement using PerfMonStorageThere are four key metrics on a storage array that are of interest,§ Front-end fibre channel ports/CPU§ Cache (memory slots)§ Back-end directors CPU§ Disks (fibre channel)© 2013 VCE Company, LLC. All Rights Reserved.61

Figure 41. Front-end fibre channel ports/CPUNote: The front-end fibre channel ports were less than 36% used.© 2013 VCE Company, LLC. All Rights Reserved.62

Figure 42. Cache (memory slots)Note: Write pending count is data that is in a cache slot waiting to be written to disk. In this example, for theFICO run, the write pending count (approximately 11,000) is much less than the write pending limit(650,000).© 2013 VCE Company, LLC. All Rights Reserved.63

Figure 43. Back-end directors CPUNote: Back-end directors were less than 25% used. These are the CPUs of the storage array that move the datafrom memory slots to disks.© 2013 VCE Company, LLC. All Rights Reserved.64

Figure 44. Disks (fibre channel)Note: Disk use percentage was 50% max but did not affect the write response times since the write pending limitwas not reached.© 2013 VCE Company, LLC. All Rights Reserved.65

ABOUT VCE VCE, formed by Cisco and EMC with investments from VMware and Intel, accelerates the adoption of converged infrastructure andcloud-based computing models that dramatically reduce the cost of IT while improving time to market for our customers. VCE,through the Vblock Systems, delivers the industry's only fully integrated and fully virtualized cloud infrastructure system. VCEsolutions are available through an extensive partner network, and cover horizontal applications, vertical industry offerings, andapplication development environments, allowing customers to focus on business innovation instead of integrating, validating, andmanaging IT infrastructure.For more information, go to www.vce.com.Copyright 2013 VCE Company, LLC. All Rights Reserved. Vblock and the VCE logo are registered trademarks or trademarks of VCE Company, LLC and/or itsaffiliates in the United States or other countries. All other trademarks used herein are the property of their respective owners.© 2013 VCE Company, LLC. All Rights Reserved.