VBLOCK POWERED SOLUTION FOR SAP: USE CASE AND PERFORMANCE RESULTS

Transcription

1 VBLOCK POWERED SOLUTION FOR SAP: USE CASE AND PERFORMANCE RESULTS REV 1.0 Date 11/08/ Cisco EMC VMware. All rights reserved. 1

2 Table of Contents Executive Summary...5 Overview...5 Business Case...5 Product Solution...5 Key Results...6 Introduction...7 Purpose...7 Scope...7 Audience...7 Technology Overview...8 Cisco network infrastructure...8 Cisco UCS 5100 Series Blade Server Chassis...8 Cisco UCS B200-M1 Blade Server...8 Cisco UCS B250-M1 Blade Server...8 Cisco MDS 9222i Multiservice Modular Switch...9 Cisco UCS 6120 Fabric Interconnect...9 Cisco Nexus 7000 Series Switch...9 EMC storage infrastructure Hardware EMC Symmetrix VMAX EMC Celerra NS-G Software EMC RecoverPoint EMC Ionix Unified Infrastructure Manager (UIM) VMware virtualization VMware vsphere VMware VMotion VMware Distributed Resource Scheduler VMware Distributed Power Management VMware Site Recovery Manager Cisco EMC VMware. All rights reserved. 2

3 Landscape and environment Configuration Vblock 2 configuration SAP server configuration SAP production environment instance on Vblock Summary comparison of environments HP LoadRunner performance testing landscape Testing methodology and results Introduction Methodology SAP environment performance testing Data center operations testing Infrastructure Metrics Server Storage I/O VMware vsphere SolarWinds Performance Comparison and Utilization Introduction RTC Run FICO RUN Application performance comparison OTC RUN Application performance comparison Performance comparison Resource utilization Performance Analysis and Key Contributors Processor architecture and configuration UCS integrated and converged fabric configuration Virtual application server dynamic performance tuning Optimization and balancing of compute, network, and storage throughout the Vblock Cisco EMC VMware. All rights reserved. 3

4 SAP on Vblock use cases Deployment and scaling of servers (vcpu, vmemory) SAP recovery using EMC RecoverPoint CRR Performing recovery using RecoverPoint bookmarks Stateless computing Dynamic on-demand provisioning Conclusion Appendix A: Performance and Comparison Results Requisition-to-check (RTC) Run Application performance RTC run 4x Resource utilization Network utilization I/O utilization FCoE utilization CPU/vCPU Storage FICO RUN Application performance comparison Resource utilization for I/O Resource utilization for FCoE CPU Storage OTC RUN Application performance comparison I/O Resource utilization FCoE resource utilization vsphere CPU Storage Cisco EMC VMware. All rights reserved. 4

5 Executive Summary Overview Large multifaceted data center organizations are under increasing pressure to reduce operating and capital costs through virtualization technologies while also being asked to improve application availability and performance. The Vblock Infrastructure Platforms (hereafter referred to as a Vblock) provides administrators and architects the capability to not only virtualize business-critical and resource-intensive applications such as SAP, but also recognize return on investment through improved performance and efficiency. This white paper addresses how SAP can be virtualized in a Vblock environment to achieve significant improvements in application performance compared to a typical retail customer environment using Cisco network infrastructure, EMC storage and information infrastructure, and VMware virtualization technologies. This document also provides actual test data and results illustrating the differences between SAP performance in nonvirtualized and virtualized environments. Within this white paper, test data and results are provided in charts and graphs to demonstrate the significant performance improvements realized in the Vblock environment. Performance analysis of these results is also given, providing a context to what the results actually mean in production and test environments. Business Case Enterprise organizations need to validate the feasibility of virtualizing mission-critical applications like SAP in their data center environments as part of an overall private cloud strategy. To address their concerns about virtualizing SAP and placing it into the private cloud, administrators must have assurances that application performance and operation, will in fact provide significant improvements. By adopting a private cloud strategy and virtualizing SAP through the use of the Vblock, customers can achieve key business objectives to reduce costs through virtualization while also significantly improving application performance through ease of use. Product Solution This white paper presents information on the performance of the SAP on Vblock solution in a virtualized environment, compared to a retail customer production and test environment in a non-virtualized environment. The test configuration was designed to support SAP running 6 application servers with close to 20,000 SAPS on the Database Server and close to 9,000 SAPS on each application server in the non-virtualized environment. Then, we ran a performance comparison between this configuration and the Vblock configuration Cisco EMC VMware. All rights reserved. 5

6 Key Results The following list details the key improvements observed during SAP On Vblock testing: Performance improvement of 50% or more when running SAP on the Vblock compared with a retail customer s production and test environments. Reduced complexity when configuring and deploying SAP, unlike physical server and database environments which can be hampered by capacity, storage, and compute resource limitations. Increased scalability to dynamically add resources to a running virtual SAP dialog instances. Ability to perform SAP recovery using RecoverPoint continuous remote replication. Support for Stateless Computing; allowing Vblock service profiles to be migrated across the environment without negatively impacting running systems. Simplified provisioning of new SAP servers through orchestration and automation Cisco EMC VMware. All rights reserved. 6

7 Introduction Data center virtualization allows administrators and data center architects to allocate resources more efficiently and to significantly reduce operational and production costs. Virtualization technology has matured to the point where it is now suitable for deploying mission critical applications, such as SAP, in large data center environments. Today's business imperatives for IT demand that the deployment of applications such as SAP be performed securely and safely, without impacting production environments. With the availability of Vblock Infrastructure Platforms (hereafter referred to as Vblock) in the marketplace, the deployment of SAP on this platform meets the most demanding customer requirements. By virtualizing SAP in a Vblock environment, the following benefits are realized: Equal or better performance when compared to existing non-virtualized implementations Flexibility when adding, upgrading, and removing computing resources Simplicity and flexibility of SAP provisioning and operation Enhanced infrastructure monitoring Business continuity/disaster recovery using Cisco, EMC, and VMware technologies Purpose This document describes how SAP was virtualized using Vblock Infrastructure Platforms, including several test scenarios with included performance metrics and comparisons that demonstrate the benefits of SAP on the Vblock. In addition, this document describes a subset of value-added use cases that are available when SAP is deployed within a private cloud infrastructure. The purpose of this document is to describe how the: SAP solution was migrated to an offsite Vblock environment. New environment was configured, tested, and validated to exceed the performance of a legacy environment. Advanced functionality of the Vblock was used in value-add use cases, and validated within a performance-testing environment. Scope The scope of this document provides a focused evaluation of the SAP landscape in a Vblock environment and is applicable to a wide variety of SAP landscapes that could be virtualized to take advantage of the enhanced functionality of Vblock. Audience This document was written for customers interested in learning about an SAP on Vblock environment, which includes SAP and infrastructure administrators and architects, as well as other individuals tasked with evaluating, acquiring, managing, operating, or deploying SAP in a virtualized data center environment Cisco EMC VMware. All rights reserved. 7

8 Technology Overview Cisco network infrastructure This section describes the blade server technology used in the UCS environment. Cisco UCS 5100 Series Blade Server Chassis The UCS 5108 Blade Server Chassis comprises rack units (six rack units [6RU] high), mounted in a 19-inch rack and used standard front-to-back cooling. This chassis can accommodate up to eight half-width, or four full-width, Cisco UCS B-Series Blade Servers within the same chassis. The benefits of the 5108 Blade Server Chassis are: Fewer physical components No independent management was required Increased energy efficiency compared to traditional blade-server chassis The 5108 chassis also eliminates the need for dedicated chassis management and blade switches, reduces cabling requirements, and allows scalability to 40 chassis without additional complexity. Cisco UCS B200-M1 Blade Server Based on Intel Xenon 5500 Series processors, these blade servers adapt processor performance to application demands and intelligently scale energy-use based on utilization. Each server uses network adapters for consolidated access to the unified fabric, which reduces the number of adapters, cables, and access-layer switches needed for LAN and SAN connectivity. Cisco UCS B250-M1 Blade Server The Cisco UCS B250 M1 Extended Memory Blade Server is designed to maximize performance and capacity for the most demanding virtualization and large dataset applications. The server is a full-width, two-socket blade server with increased throughput and more than double the amount of industry-standard memory compared to traditional two-socket x86 servers. Each Cisco UCS 5108 Blade Server Chassis can house up to four UCS B250 M1 Blade Servers (maximum 160 per Unified Computing System). The UCS B250 M1 features include: Up to two Intel Xeon 5500 Series processors, which automatically and intelligently adjust server performance according to application needs, increasing performance when needed and achieving substantial energy savings when not. Up to 384 GB of DDR3 memory for demanding virtualization and large data-set applications. Alternatively, this technology offers a more cost-effective memory footprint for less-demanding workloads. Two optional Small Form Factor (SFF) Serial Attached SCSI (SAS) hard drives available in 73GB 15K RPM and 146GB 10K RPM versions with an LSI Logic 1064e controller and integrated RAID. Two dual-port mezzanine cards for up to 40 Gbps of I/O per blade. Mezzanine card options include either a Cisco UCS VIC M81KR Virtual Interface Card, a converged network adapter (Emulex or QLogic compatible), or a single 10GB Ethernet Adapter Cisco EMC VMware. All rights reserved. 8

9 Cisco MDS 9222i Multiservice Modular Switch The Cisco MDS 9200 Series Multilayer Switches integrate high-performance Fibre Channel and IP into a single module and provide the following benefits: High-density Fibre Channel switch that scales up to 66 Fibre Channel ports Integrated hardware-based virtual fabric isolation with virtual SANs (VSANs) and Fibre Channel routing with inter-vsan routing High-performance intelligent application with the combination of a 16-port Storage Services Node Multiprotocol and mainframe support (Fibre Channel, FCIP, Small Computer System Interface over IP [iscsi], and IBM Fibre Connection [FICON]) Remote SAN extension with high-performance Fibre Channel over IP (FCoIP) Long distance over Fibre Channel with extended buffer-to-buffer credits Platform for intelligent fabric applications such as storage media encryption In-Service Software Upgrade (ISSU) Comprehensive network security framework IPv6 capable Cisco UCS 6120 Fabric Interconnect The Cisco UCS 6100 Series Fabric Interconnects provides both network connectivity and management capabilities to all attached blades and chassis. The 6100 Series offers line-rate, low-latency, lossless 10 Gigabit Ethernet and Fibre Channel over Ethernet (FCoE) functions. In addition, by supporting unified fabric, the 6100 Series provides both LAN and SAN connectivity for all blades within its domain. Typically deployed in redundant pairs, the 6100 Series provides: High performance unified fabric with line-rate, low-latency, lossless 10 Gigabit Ethernet, and FCoE Centralized unified management with Cisco UCS Manager software Virtual machine optimized services with the support for VN-Link technologies Efficient cooling and serviceability with front-to-back cooling, redundant front-plug fans and power supplies, and rear cabling Available expansion module options that provide Fibre Channel and/or 10 Gigabit Ethernet uplink connectivity. Cisco Nexus 7000 Series Switch The Cisco Nexus 7000 Series is a modular switching system designed to deliver 10 Gigabit Ethernet and unified fabric in the data center. This platform delivers exceptional scalability, continuous operation, and transport flexibility and is primarily designed for the core and aggregation layers of the data center. The Cisco Nexus 7000 Platform is powered by Cisco NX-OS Cisco EMC VMware. All rights reserved. 9

10 EMC storage infrastructure Hardware EMC Symmetrix VMAX The EMC Symmetrix VMAX storage system provides high-end storage for the virtual data center. Symmetrix VMAX scales up to 2 PB of usable protected capacity and supplies the power to consolidate more workloads with a much smaller footprint than alternative arrays. Its innovative EMC Symmetrix Virtual Matrix Architecture seamlessly scales performance, capacity, and connectivity on-demand to meet all application requirements. Symmetrix VMAX can be deployed with Flash, Fibre Channel, and Serial Advanced Technology Attachment (SATA) drives. It supports virtualized and physical servers including open systems, mainframe, and system hosts. EMC Celerra NS-G2 The EMC Celerra NS-G2 is an entry-level IP storage gateway that consolidates storage from multiple applications and file servers. Celerra NS-G2 delivers fast file access, high availability, and advanced functionality to existing Storage Area Network (SAN) infrastructures. With Celerra NS-G2 you can leverage simultaneous, concurrent support for NFS, CIFS, and iscsi protocols and scale to 128TB of usable capacity. Add EMC Celerra Multi-Path File System (MPFS) to improve performance over traditional network-attached storage (NAS) deployments, enabling your business to grow dynamically. Software EMC RecoverPoint EMC RecoverPoint provides continuous data protection and continuous remote replication for on-demand protection and recovery to any-point-in-time. RecoverPoint's advanced capabilities include policy-based management, application integration, and bandwidth reduction. With RecoverPoint, a single, unified solution can be implemented to protect and/or replicate data across heterogeneous storage. Management can be simplified and costs reduced, data recovered at a local or remote site to any point in time, and continuous replication to a remote site verified without impacting performance. EMC Ionix Unified Infrastructure Manager (UIM) EMC Ionix Unified Infrastructure Manager (UIM) provides simplified management for Vblock Infrastructure Platforms, including provisioning, configuration, change, and compliance management. By managing Vblocks as a single entity, operational expenses and integrated management for Vblock network, compute, and storage resources can be dramatically reduced. With a consolidated dashboard view, policy-based management, automated deployment, and deep visibility across the Vblock environment, EMC Ionix UIM is integral and essential to effectively and efficiently manage Vblock Infrastructure Platforms Cisco EMC VMware. All rights reserved. 10

11 VMware virtualization VMware vsphere VMware vsphere is a cloud-based operating system that transforms data centers into simplified environments to enable the next-generation of flexible, reliable IT services. A cloud operating system is a new category of software specifically designed to holistically manage large collections of infrastructure. As a seamless, flexible and dynamic operating environment, vsphere includes the latest VMware hypervisor, ESX 4. This creates a layer of abstraction between the resources required by an application and operating system, and the underlying hardware that provides those resources. VMware VMotion VMware VMotion enables the live migration of running virtual machines from one physical server to another with zero downtime, continuous service availability, and complete transaction integrity. VMotion is a key enabling technology for creating the dynamic, automated, and self-optimizing datacenter. VMware Distributed Resource Scheduler VMware Distributed Resource Scheduler (DRS) aggregates computing capacity across a collection of servers into logical resource pools and allocates available resources among the virtual machines based on pre-defined rules that reflect business needs and changing priorities. VMware Distributed Power Management VMware Distributed Power Management (DPM), included with VMware DRS, automates power management and minimizes power consumption across the collection of servers in a VMware DRS cluster. VMware Site Recovery Manager VMware Site Recovery Manager is a disaster recovery management and automation solution for VMware vsphere 4. Site Recovery Manager accelerates recovery by automating the recovery process and simplifies management of disaster recovery plans by making disaster recovery an integrated element of managing the VMware virtual infrastructure. Site Recovery Manager also ensures reliable recovery by eliminating complex manual recovery steps and enabling non-disruptive testing of recovery plans. Site Recovery Manager integrates tightly with VMware vsphere, VMware vcenter Server and storage replication products from EMC to make failover and recovery rapid, reliable, affordable, and manageable Cisco EMC VMware. All rights reserved. 11

12 Landscape and environment Configuration Vblock 2 configuration There are three major components within the Vblock: storage, servers, and unified fabric including network/switches. Table 1 describes the Vblock 2 configuration that was used for this testing. Table 1. Vblock 2 configuration Component Cisco Unified Computing System Configuration 1 x Cisco B250 Blade MS Windows 2003 Server x64 MS SQL 2005 Enterprise Edition SP3 CU4 4 x Cisco B200 Blades VMware vsphere servers Storage Storage Area Network SAP Central Instance and SAP Dialog Instances on virtual machines EMC Symmetrix VMAX Cisco MDS 9222i Switches 2011 Cisco EMC VMware. All rights reserved. 12

13 SAP server configuration This section covers specific configuration information for the SAP server. The key point to note here is that only the database server was physical; the rest of the servers were configured as virtual servers within the Vblock. Table 2 describes the SAP server configuration. Table 2. SAP server configuration Component Database server (B250 Blade) running on physical hardware Storage Configuration 12 CPU cores (2 x six-core Westmere X GHz) 192 GB RAM 22 x 320 GB Data Volumes 8 x 30 GB Temp DB Volumes 1 x 200 GB Logs Volume 1 x 2 TB Volume for Backup/Restore Volume 1 x 50 GB SAP Executables Volume 1 x 350 GB OS, SQL and Pagefile Volume 1 x 25 GB Clustered SQL main mount point Volume Application servers running on VMware vsphere (B200 Blades) SAP Application Server VMware vsphere 4 Storage Quest LightSpeed used for backup\restore 8 CPU cores (2 x quad-core Nehalem X GHz) per blade 96 GB RAM per blade 4x4 vserver 40 GB RAM 3x6 vserver 40 GB RAM 25 GB Boot Volume 100 GB Host Volume This section also describes the high-level configuration of the SAP environment on Vblock. The Production/QA/Test /Dev SAP environments were virtualized and resided on the Cisco UCS. EMC Symmetrix VMAX provided tiered storage based on performance expectations through a SAN network to the SAP landscape Cisco EMC VMware. All rights reserved. 13

14 SAP production environment instance on Vblock The configuration team was able to realize a key benefit of the Vblock: the ability to support multi-tier architectures running either physical, virtual, or mixed modes. To demonstrate this capability, an MS SQL Database Server was installed and configured for a retail customer s SAP Production Environment system on a physical host. Using four ESX hosts, eight virtual machines were then created using five UCS blade servers to build the SAP landscape. The primary components of the SAP landscape were: 1 x SAP Central Instance 7 x SAP Application Servers Figure 1 shows the SAP landscape running on a Vblock 2 configuration at the virtual, physical, and storage layers. Figure 1. SAP landscape running on Vblock 2 Note: MSSQL2005 Server is installed on a physical host while SAP Central instance and Dialog instances are installed on virtualized hosts. The backend storage used for this setup is EMC Symmetric VMAX Cisco EMC VMware. All rights reserved. 14

15 Virtual layer The entire Production landscape is installed using four Cisco UCS B200 half-blade servers running on VMware ESX. Each blade server consists of an 8-core CPU and 96 GB RAM. Physical layer The MS SQL Database Server is hosted on one Cisco UCS B250-M2 full-blade server equipped with a 12-core CPU and 192 GB RAM. All of these blade servers reside on one UCS chassis. A redundant pair of Cisco UCS 6120 Fabric Interconnects is incorporated within the Vblock to offer both 10 Gigabit Ethernet and Fibre Channel over Ethernet (FCoE) functionality. By supporting unified fabric, the Fabric Interconnect provides both LAN and SAN connectivity for all blades within its chassis. Storage layer The high-end EMC Symmetrix VMAX storage array supports both virtualized and physical servers. The high-density Cisco MDS 9222i Multiservice Modular Switch connects the UCS blades through a Fibre Channel storage area network. Summary comparison of environments Table 3 shows the major configurations for the retail customer s Production and Test environments, as well as the VCE Vblock environment. Table 3. Summary comparison of environments Summary Production Test Vblock DB Server 22 cores x 1.6 GHz (IA64/Itanium), 176 GB 24 cores x 2.8 GHz (Opteron), 192 GB 12 cores x 2.93 GHz (Nehalem/Westmere) 192 GB Database MS SQL 2005 MS SQL 2005 MS SQL 2005 Operating System MS Windows 2003 Server MS Windows 2003 Server MS Windows 2003 Server Central Instance On App Server Tier On App Server Tier On App Server Tier App Server Environment 8 cores x 2.6 GHz (Opteron), 32 GB each 8 cores x 2.4 GHz(Xeon) 32 GB each 4x4 Vserver 40 GB RAM 3x6 Vserver 40 GB RAM App Server # 6 6 HP Proliant BL680c G5 8 Estimated SAPS on DB Server Estimated rating ~19,388 Estimated SAPS on App Server (each) SAP 2-tier SD Benchmark: 25,550 Estimated rating: 22, HP LoadRunner N/A V 9.5 V 9.5 SAP 2-tier SD Benchmark : 25,500 (approx.) Virtual Users Per Generator N/A 250 (5 second frequency, 120 runs) 250 (5 sec frequency, 120 runs) Load Generators N/A Cisco EMC VMware. All rights reserved. 15

16 The following definitions apply to each environment in this table: Production the environment where the customer was actually running SAP. This can be referred to as the as-is environment. Test the environment the customer was planning to implement after performance testing was completed based on a new vendor platform. A copy of the existing Production environment was used. This can be referred to as the to be environment. Vblock the Vblock environment used to measure performance against the Test environment at the customer site Cisco EMC VMware. All rights reserved. 16

17 HP LoadRunner performance testing landscape The LoadRunner environment was also set up on the Vblock providing direct access to SAP application. Figure 2 shows the SAP PE2 landscape on Vblock. According to the virtualized application servers (also known as dialog instances), the number of servers, amount of memory, and number of processor cores assigned could vary from test run to test run. HP Performance Center and HP LoadRunner 9.5 tools were used to generate a load on the PE2 Vblock environment. LoadRunner was used to stress the PE2 Vblock environment by executing OTC, RTC, and FICO business processes. This tool was also used to perform data analysis. Business processes (implemented as scripts) were created with the Virtual User Generator (Load Runner s scripting tool), which was later imported into the Controller (Performance Center) to execute the test scenario outlined during the planning phase of the project. Figure 2. LoadRunner landscape for SAP on Vblock Note: The above diagram shows the Load Runner landscape using 2 virtualized blade servers running 11 virtual machines. Of these virtual machines, one VM was configured as Load Controller and 10 VMs were being used as Load Generators Cisco EMC VMware. All rights reserved. 17

18 Testing methodology and results Introduction The SAP on Vblock solution described in this document, consisting of a virtualized SAP instance on the Vblock, required a number of tests to be performed on a SAP database (SAP DB), Central Instance (CI), and an application server configuration comparable to what would might be seen in typical Production and Test environments in order to demonstrate the significant performance improvements that can be expected when running SAP on a Vblock. Performance results between a virtualized SAP on Vblock landscape and a nonvirtualized SAP landscape are detailed in this document. Performance testing was compared to 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 capacity limits Server, storage, and network components Deployment and scaling of servers Dynamic resource allocation Migration of various components The purpose of this testing was to demonstrate the following characteristics of SAP on Vblock: Meets or exceeds existing physical environment performance using Vblock Infrastructure Platforms Analysis of the key attributes to the performance pertaining to the Vblock design Demonstrate the efficiency of resource provisioning on Vblock 2011 Cisco EMC VMware. All rights reserved. 18

19 Methodology The above stated tests were successfully performed using various tools and techniques. While it required subject matter expertise to perform these tests; only Vblock and SAP standard procedures and methods were used to attain the benchmark results. The test results provided in this document were gathered using various systems and application administration tools. Testing experts compared the performance of the Vblock system with what might be seen in a traditional customer environment and divided the testing into two major areas: Application (SAP environment) Data center operations (Vblock) environments, listed below. SAP environment performance testing The SAP environment performance testing included two major components: HP LoadRunner for interactive performance testing HP LoadRunner was used to simulate a user/transaction load that is equivalent to the load simulated by the testing team. Batch processing The batch workload was reproduced, where possible. Additional batch and dialog instance load testing was conducted to significantly increase the workload on the system to identify capacity limits. In addition to the analysis of the LoadRunner results, utilization statistics were gathered at the infrastructure levels during batch processing. Data center operations testing The data center operation testing was limited to three major categories: Addition of resources to a running virtual SAP dialog instance The testing team demonstrated the ability to add resources, such as vcpu and vmemory to a running virtual SAP dialog instance. The team also successfully added vcpus (up to eight) and memory (up to 80 GB RAM) to a SAP dialog instance running on a virtual machine. The addition of vcpus and memory required a restart of the virtual machine. When the SAP dialog instance was restarted, the additional vcpu and memory were immediately apparent (in SAP transaction OS06). Migration of service profiles The testing team demonstrated and validated the nature of stateless computing on a Vblock by migrating the Vblock service profiles from one physical blade server to another. The relevant use cases were: o Hardware migration o Hardware maintenance o Hardware upgrade o Recovery in the event of hardware failure Operational testing The operation-level testing was completed to demonstrate the versatility of the Vblock and summarize the flexibility and agility of the Vblock. These use cases included the following operational tests: o Deployment and scaling of the SAP application o On-demand provisioning of resources o Systems monitoring and management including patches and routine maintenance 2011 Cisco EMC VMware. All rights reserved. 19

20 Infrastructure Metrics Performance monitoring tools were an important part of the testing process; in both physical and virtualized 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 performance requirements were met. For testing, the following performance monitoring tools were used to measure performance: Server The following performance monitoring tools were used during the RTC, OTC and FICO runs to measure database performance and CPU usage: Physical server PerfMon: PerfMon is an SNMP-based performance tool that was used to measure database and CPU performance and usage while a series of SAP RTC, OTC, and FICO tests were executed on the Vblock. Virtual server VMware vcenter Performance Charts and ESXTOP The performance counters maintained by vcenter and accessed via the VI client were used to monitor the performance of the virtualized customer environment. Alternatively, VMware s ESXTOP was executed on the COS command line to provide real-time views of ESX server and virtual machine performance. Storage I/O Storage and I/O performance were measured using the EMC Symmetrix VMAX STP tool. STP can be used as a workload analyzer to collect performance statistics on a Symmetrix VMAX storage array. In the case of this testing, STP was used to measure storage performance while RTC, OTC and FICO runs were executed on the Vblock. VMware vsphere VMware vsphere TM was used to take advantage of the capability to view CPU, memory, disk, and network 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 entire environment Thumbnail views of virtual machines, hosts, resource pools, clusters, and datastores Drill-down capability to perform root cause analysis of problems Detailed storage views showing usage by file type SolarWinds SolarWinds was used to measure network and fabric-level performance of the Vblock Cisco EMC VMware. All rights reserved. 20

21 Performance Comparison and Utilization Introduction This is the most critical section in this report because it contains comparison of the performance and utilization of infrastructure resources while the environment was subjected to three critical business processes: RTC OTC FICO Note: The RTC/OTC and FICO performance results were based on workload generating scripts provided by the customer to measure the business process performance of the Vblock environment compared to the customer Test environment. This section covers two major areas: A summary of the business process performance. Details of the underlying resource utilization from an infrastructure perspective. The following three tests were run on the Vblock: RTC run OTC run with a 3x6 virtual machine configuration FICO run with a 3x6 virtual machine configuration For each of the above runs, application, vsphere/servers and storage level performance comparisons were performed, along with resource utilization Cisco EMC VMware. All rights reserved. 21

22 RTC Run Table 4. Performance statistics SAP RTC Transactions Customer Vblock % SAPGUI_IDOC_17_VAR1_RTC_EXECUTE % SAPGUI_IDOC_17_VAR2_RTC_EXECUTE % SAPGUI_IDOC_338_VAR1_RTC_EXECUTE % SAPGUI_IDOC_338_VAR2_EXECUTE % SAPGUI_MB51_RTC_EXECUTE % SAPGUI_ZPTR_MAIN_RTC_EXECUTE % SAPGUI_ZPTR_VAR1_RTC_EXECUTE % % Figure 3. Performance Statistics Note: The figure above shows the comparison of performance response time between the Vblock and the customer s Test platform. Results show that the Vblock was able to process 7 business critical RTC transactions with an improved average response time of 59% Cisco EMC VMware. All rights reserved. 22

23 FICO RUN Application performance comparison Table 5 and Figure 4 illustrate the performance improvements seen when running SAP FICO transactions in the Vblock environment, as compared to the customer environment. Table 5. FICO 2nd run 3x6 SAP FICO Transactions Customer Vblock % SAPGUI_FAGLB03_FICO_EXECUTE % SAPGUI_FAGLL03_FICO_EXECUTE % SAPGUI_FBL1N_FICO_EXECUTE % SAPGUI_FBL5N_FICO_EXECUTE % SAPGUI_KE24_FICO_EXECUTE % SAPGUI_KE30_VAR1_FICO_EXECUTE % SAPGUI_KE30_VAR2_FICO_EXECUTE % SAPGUI_ZGRIRAGING_FICO_EXECUTE % SAPGUI_ZPOACCRUAL_FICO_EXECUTE % % 2011 Cisco EMC VMware. All rights reserved. 23

24 Figure 4. SAP FICO transactions running on three virtual application servers Note: The figure above shows the comparison of performance response time between the Vblock and the customer s Test platform. Results show that the Vblock was able to process 9 business critical FICO transactions with an improved average response time of 72% 2011 Cisco EMC VMware. All rights reserved. 24

25 OTC RUN Application performance comparison Table 6 and Figure5 illustrate the performance improvements seen when running SAP OTC transactions in the Vblock environment, as compared to the customer environment. Table 4 OTC run 3x6 SAP OTC Transactions Customer Vblock % SAPGUI_VA41_OTC_DATA_EXECUTE % SAPGUI_VKM1_VAR2_OTC_EXECUTE % SAPGUI_VKM1_VAR3_OTC_EXECUTE % SAPGUI_ZBACKORDER_VAR1_OTC_EXECUTE % SAPGUI_ZBACKORDER_VAR2_OTC_EXECUTE % SAPGUI_ZDLVSTATUS_OTC_EXECUTE % SAPGUI_ZNOBACKORDER_OTC_EXECUTE % SAPGUI_ZVA14L_OTC_EXECUTE % SAPGUI_ZVASSUMM_VAR1_OTC_EXECUTE % SAPGUI_ZVASSUMM_VAR2_OTC_EXECUTE % SAPGUI_ZVENDORMARK_OTC_EXECUTE % SAPGUI_ZWORKLOAD_MAIN_EXECUTE % SAPGUI_ZWORKLOAD_VAR1_OTC_EXECUTE % SAPGUI_ZWORKLOAD_VAR2_OTC_EXECUTE % % 2011 Cisco EMC VMware. All rights reserved. 25

26 Figure 5. SAP OTC transactions running on three virtual appliccation servers Note: The figure above shows the comparison of performance response time between the Vblock and the customer s Test platform. Results show that Vblock was able to process 14 business critical OTC transactions with an improved average response time of 46%. Performance comparison The performance comparison was completed for application, vsphere, and storage components from the application performance availability and utilization perspectives: Resource utilization In this section, the focus was on the Vblock at the component level. The resource utilization was captured to understand the overall performance of the Vblock from an infrastructure perspective, while running SAP as one of the solutions. The test team was interested in the following utilization of the following key components of the Vblock while running SAP. Network Storage Servers CPU 2011 Cisco EMC VMware. All rights reserved. 26

27 From the virtual machines perspective, the four application servers (4 x vcpu VMs) used were: SAPCL55 SAPCL53 SAPCL54 SAPCL Cisco EMC VMware. All rights reserved. 27

28 Performance Analysis and Key Contributors The significant performance metrics and measurements described in the previous section can be realized due to a number of improvements in storage and application layout, network optimization, and inherent advantages of the Vblock, with its optimized multi-application compute system. The following key factors contributed to the superior performance improvements observed in the test results provided in this configuration report: Processor architecture and configuration The Xeon 5570 process was shown in testing to exceed the performance of the Opteron processor in server benchmark testing (1.6 times faster); while the Xeon 5680 (used in these tests) was observed to far exceed the 5570 s performance by an additional 43%, leading the combination of the Xeon 5680 and UCS B250 server to vastly outperform Opteron-based HP servers. Figure 6. Cisco UCS B250 M2 performance UCS integrated and converged fabric configuration One of the key factors in understanding how these performance results exceeded expected results is in the UCS blade configuration. Because the SAP layout enables the database server (physical), all app servers (virtual), and LoadRunner clients (virtual) to reside on a single chassis connected to a set of 6120 fabric interconnects, the majority of SAP traffic remains internal, thus taking advantage of the large amount of bandwidth available Cisco EMC VMware. All rights reserved. 28

29 Virtual application server dynamic performance tuning Application server virtual machines in the Vblock were sized and numbered to approximately match the SAPS capacity of the TE2 application tier, which was 3 x 8775 approx = SAPS. In vsphere, four- way application servers are a sweet spot and the SAPS rating of a four-way virtual machine is estimated to be Based on 6250 SAPS per four-way virtual machine, four application servers were required to approximately match the TE2 app tier rating. After initial testing with a 4 x 4 application server VMS configuration, an uneven distribution in the CPU utilization was observed, whereby 1-2 of the virtual machines were at 100% CPU utilization, while the remaining virtual machines were relatively underutilized. This was attributed to imperfect load balancing of the virtual users as they were ramped up by LoadRunner. In order to more evenly distribute CPU utilization across the application tier and reduce a virtual machine from spiking to 100%, the number of virtual machines was reduced and then made larger in size. The next sizing configuration to reflect this and also roughly match the TE2 application tier SAPS rating was 3 x 6-way virtual machines. The SAPS rating of a 6-way VM is approximately between SAPS (estimated from 4- and 8- way benchmark certs and which shows approximate linear scalability). Optimization and balancing of compute, network, and storage throughout the Vblock Performance testing showed that less than 25% of cache, disk, and front-end and back-end ports were utilized. The Symmetrix VMAX storage array can handle much larger workloads, thus validating a key design point of optimization and balancing of compute, network and storage throughout the Vblock. In this example, a Vblock 2 minimum configuration was designed with four UCS chassis with corresponding network and storage capacity. The customer test bed consumes one UCS chassis, and thus, less than 25% of storage resources Cisco EMC VMware. All rights reserved. 29

30 SAP on Vblock use cases This 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 service profiles Dynamic on-demand provisioning Deployment and scaling of servers (vcpu, vmemory) The testing team demonstrated the ability to add resources, such as vcpu and vmemory, to a running virtual SAP dialog instance. The team successfully added vcpus (up to eight) and memory (up to 80 GB RAM) to an SAP dialog instance running on a virtual machine. The addition of vcpus and memory required restarting the virtual machine. Once the SAP dialog instance was restarted, the additional vcpu and memory were immediately apparent (in SAP transaction OS06). Application server virtual machines in the Vblock were sized and numbered to approximately match the SAPS capacity of the customer. The TE2 application tier was 3 x 8775 (approx ) SAPS. When using vsphere, four-way application servers were considered to be the sweet spot: The SAPS rating of a four-way VM is estimated at 6250 (source: SD benchmark cert ). Based on 6250 SAPS per four-way VM, the team required four of these to approximately match the TE2 application tier rating. After initial testing with 4 x 4 application server VMs, the team observed an uneven distribution in the CPU utilization where one or two of the VMs were at 100% vcpu while the remaining VMs were relatively underutilized. The team attributed this to imperfect load balancing of the virtual users by LoadRunner. To distribute vcpu utilization more evenly across the application tier, and also to prevent any VM from spiking to 100%, the team reduced the number of VMs but made them larger. The next appropriate sizing configuration (which also approximates the TE2 application tier SAPS rating) was 3 x 6-way VMs. The SAPS rating of a 6-way VM was approximately between 8000 and 9000 SAPS (estimated from 4- and 8-way benchmark cert s and , which show approximate linear scalability). The following data was obtained from ESXTOP, with the data captured as a batch file and viewed in ESXplot (freeware from :// The metric shown below is the percentage (%) used of the virtual machine. As each virtual machine is 4 x VCPU, the percentage utilized needs to be divided by 4 (see the following link for explanation ://communities.vmware.com/docs/doc-9279, section %USED ) 2011 Cisco EMC VMware. All rights reserved. 30

31 Figure 7. SAPCL55 Application Server VM Performance (CPU %used) 2011 Cisco EMC VMware. All rights reserved. 31

32 Figure 8. SAPCL53 Application Server VM Performance (CPU %used) 2011 Cisco EMC VMware. All rights reserved. 32

33 Figure 9. SAPCL54 Application Server VM Performance (CPU %used) 2011 Cisco EMC VMware. All rights reserved. 33

34 Figure 10. SAPCL59 Application Server VM Performance (CPU %used) 2011 Cisco EMC VMware. All rights reserved. 34

35 SAP recovery using EMC RecoverPoint CRR If you need to install a software update, apply a patch, or perform testing on your SAP production data, you should capture a point-in-time when you know that the data is accurate using EMC RecoverPoint technology, which allows continuous data protection, either locally or remotely through the use of bookmarks. EMC RecoverPoint continuous data protection technology allows you to perform the following actions in an SAP environment: Local protection (CDP) Remote replication (CRR) Provide protection for any point in time Present any point in time to another host in the SAP environment For this testing, RecoverPoint CRR was set up in a heterogeneous storage environment. Replication was performed from a Vblock 2 to a Vblock 1, and the configuration used array-based splitter technology on the CLARiiON storage of the Vblock 1 and SANTAP-based splitter technology on the VMAX storage of the Vblock 2. Heterogeneous replication was then performed on the boot LUN and remaining SAP LUNs. The boot LUN was replicated from the primary UCS to the DR UCS. The system was fully booted at the DR site without affecting the primary (production) site as shown in Figure 11. Figure 11. Customer SAP Boot running on RPA Cisco EMC VMware. All rights reserved. 35

36 Performing recovery using RecoverPoint bookmarks You can view and manage your SAP environment through the RecoverPoint GUI, and protect the environment based on individual LUNs or groups of LUNs. Using RecoverPoint bookmarks, you can create reference points in the indefinitely granular landscape of point-in-time protection, which you can use to perform a production rollback, if necessary. To create a bookmark: 1. In the RecoverPoint GUI, click on the Bookmark link. The Create a bookmark image for SAP Solutions Manager page appears. 2. Enter a name for the bookmark in the Bookmark Name field and click OK. To enable image access: 1. On the Recovery GUI, click on 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 to the recovery server. 2. Select one of the following options to enable image access: o Select the latest image, which selects the latest image saved o Select an image from the list, which allows you to select from a list of saved images o Specify desired point in time, which allows you to select a specific point in time 3. Select Groups from the RecoverPoint GUI menu and select Group Sets. This then allows you to create a new consistency group. To create a new consistency group: 1. 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 sets how often bookmarks will be created across your consistency groups and allows you to have granularity to roll back just one at a time, or present only one bookmark to the recovery server while still maintaining a common point in time across all three consistency groups in your SAP environment. To bring up consistency groups simultaneously, you need to put the production environment into a suspend state to ensure there are no IP address conflicts. To put an SAP virtual machine in suspend state: 1. In the RecoverPoint GUI, right-click on SAP Solution Manager and select Suspend. The Confirm Suspend 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 you created earlier. If there is data corruption or data integrity loss, this bookmark allows you to roll your production data back to the point-in-times of the bookmark. 4. Enable image access to the bookmark by selecting the Image Access icon and clicking Enable Image Access. The Enable Image Access window appears. 5. Click the Select image from the list radio button and browse to the SAP Patch Installation bookmark. 6. Click Next. The Image Access Mode window appears Cisco EMC VMware. All rights reserved. 36

37 7. Select the Image Access Mode radio button. There are two options for this selection: logged access and virtual access. o o Logged access takes the point-in-time and copies the data to the target LUNs. Virtual access allows for immediate access to the data through memory mapping technologies. You can also select the Roll image in background checkbox to also copy the data to the target LUNs. You can also boot up the virtual machine to verify everything is operating properly by performing the following steps: 1. Verify that the SAP services are running in SAP Solutions Manager. 2. On the desktop for the virtual machine, click on the SAP Logon icon to login 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 that allows you to select either of the following options: o Failover to Recovery o Recover Production 2011 Cisco EMC VMware. All rights reserved. 37

38 Stateless computing In the Vblock environment, SAP instances can be seamlessly migrated between UCS blades using VMware s VMotion technology. Moving SAP instances between blades allows administrators to schedule maintenance (for example, installing a SAP kernel update, OS updates or patches, or a database update/patch) on a blade while maintaining minimal production down-time. Redundancy can also be enabled through the migration of SAP instances; ensuring that SAP production data is not lost in case of blade failure. Before moving a SAP instance from one blade to another, ensure that the following conditions are met: SAP is running in a virtual machine on an ESX Server. Both ESX Servers: o Have compatible CPUs. o Are connected to a virtual switch assigned for VMotion. o Are connected to a production switch enabled for user access. SAP virtual disk and VMFS configuration files reside on shared storage connected to both ESX Server hosts. To move a SAP instance from one UCS blade to another, perform the following steps: 1. Open the Virtual Infrastructure Client application and locate the SAP instance you want to move (for example, sap_vm). 2. Right-click on the SAP instance and click Migrate. A list of destination hosts is displayed where you can move the SAP instance. 3. Select the host you want to use to move the SAP instance and click Next. A Resource Pools page 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: o High Priority - ensures virtual machine availability during migration by reserving resources on both source and destination hosts. Low Priority - resources are NOT reserved; thus, the virtual machine may become unavailable during migration. 1. 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 (bottom pane). 2. After the migration completes, verify that the SAP instance is running on the destination host Cisco EMC VMware. All rights reserved. 38

39 Dynamic on-demand provisioning Provisioning new SAP servers on the Vblock can be simplified through the use of automation. Using customized scripts and UIM, SAP servers can be more easily managed and provisioned without requiring significant configuration and setup steps. This approach can be particularly useful for Service Providers where a rapid, errorfree and standardized approach is required Cisco EMC VMware. All rights reserved. 39

40 Conclusion This white paper was written to demonstrate the operational and performance improvements that can be realized when deploying SAP on a Vblock in a large-scale production environment. This testing demonstres that an SAP instance can be rapidly configured and deployed; unlike physical servers and databases, which are hampered by limitations of capacity, storage, and compute resources. The test team was able to configure and deploy Vblock storage, compute, and virtualization capabilities with advanced systems administration technologies. Various infrastructure changes were required throughout this exercise, allowing administrators and architects to dynamically adjust capacity, storage, and processing capabilities. Some of these benefits are documented in the use cases. The Vblock powered SAP solution defined in this document was designed to mirror a retail customer s existing production and test environments to illustrate the significant performance improvements observed when SAP was deployed on the Vblock. A series of customer provided dialog and batch workload generating scripts (RTC, OTC and FICO) runs using customer-provided workload generating scripts were performed, and performance statistics were collected, results analyzed that provided a compelling comparison against results seen in a customer s nonoptimized environment. The performance metrics and measurements contained in this report were achieved due to a number of optimizations in storage and application layout, network, and inherent advantages of the Vblock, with its optimized multi-application compute system. Within the test Vblock, one UCS chassis (8 blades) was comparable to the customer s entire SAP production farm, which averaged a performance improvement of 50% Cisco EMC VMware. All rights reserved. 40

41 Appendix A: Performance and Comparison Results Requisition-to-check (RTC) Run The team chose to cover RTC to explain the rationale behind the better performance and efficient resource utilization of SAP on a Vblock environment. Application performance From an application performance perspective, RTC was run with in 4x4 virtual server layers and contained four application servers, each configured with 4 vcpu. RTC run 4x4 Table 7 shows the performance difference between SAP within the customer environment and SAP on Vblock environments while running identical RTC scripts through HP LoadRunner. SAP on Vblock performed 59% better. The performance statistics are presented in Table 7 and Figure 12. Table7. Performance statistics SAP RTC Transactions Customer Vblock % SAPGUI_IDOC_17_VAR1_RTC_EXECUTE % SAPGUI_IDOC_17_VAR2_RTC_EXECUTE % SAPGUI_IDOC_338_VAR1_RTC_EXECUTE % SAPGUI_IDOC_338_VAR2_EXECUTE % SAPGUI_MB51_RTC_EXECUTE % SAPGUI_ZPTR_MAIN_RTC_EXECUTE % SAPGUI_ZPTR_VAR1_RTC_EXECUTE % % 2011 Cisco EMC VMware. All rights reserved. 41

42 Figure 12. Performance Statistics Note: The figure above shows the comparison of performance response time between the Vblock and the customer s Test platform. Results show that Vblock was able to process 7 business critical RTC batch jobs with an improved average response time of 59% Cisco EMC VMware. All rights reserved. 42

43 Resource utilization As shown above the RTC run was 59% better, however, resource level utilization has been remarkably better. While there were no benchmark or comparison data available from the customer, it can be stated that a duplicate customer SAP implementation could be run; this fact is clear based on Vblock resource utilization. Network utilization In a distributed environment, the major bottleneck amongst application, database and client is often determined to be the network. In the Vblock, all SAP environment components reside in the same box, creating a superhighway of sorts that allows each component to communicate more efficiently. I/O utilization Figures 13 and 14 show the I/O utilization for the two Fibre Channel (FC) connections (fc2/1 and fc2/2) from the 6120 Fabric Interconnect connected to the MDS which connects to the Symmetrix VMAX storage array. Each FC interface is capable of handling up to 4 Gbps of throughput. For this FICO run, each interface is only utilizing approximately 25 Mbps and 30 Mbps at peak intervals during the initial ramp up of the LR run. There is plenty of link capacity to spare as the utilization is under 10% utilized at their highest point. FCoE utilization from chassis to fabric interconnect was also observed during the RTC run and is illustrated in the charts displayed below. Figure 13. I/O Utilization for Fabric Interconnect Interfaces to MDS for fc2/ Cisco EMC VMware. All rights reserved. 43

44 Figure 14. I/O Utilization for Fabric Interconnect Interfaces to MDS for fc2/ Cisco EMC VMware. All rights reserved. 44

45 FCoE utilization Figures 15 and 16 show the aggregate FCoE utilization for the two most highly-utilized FCoE 10 Gbps interfaces (eth1/1 and eth1/6) from the 6120 Fabric Interconnect connected southbound to the I/O Modules for each server in the UCS chassis. For this RTC run, each interface is only utilizing approximately 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 utilization is under 10% utilized at their highest point. Figure 15. FCoE utilization from chassis to Fabric Interconnect for Ethernet1/1 Figure 16. FCoE utilization from chassis to Fabric Interconnect for Ethernet 1/ Cisco EMC VMware. All rights reserved. 45

46 CPU/vCPU The vcpu performance is shown in Figure 17 using standard server performance monitoring tools (in this case, PerfMon). The relationship between the vcpu and raw CPU can be understood by viewing the raw performance and relating this performance to the virtual machine CPU allocations. The test team did not observe a pegged vcpu; hence, the raw CPU statistics were not collected. The only situation in which CPU was pegged happened because unified load distribution was not enabled within the application layer. Figure 17 shows vcpu performance and Figure 18 shows the physical CPU performance. In the case of a virtual machine with four CPUs, the y axis must be divided by 4 to understand the performance of each vcpu. Note: During the RTC run, the Database Server CPU utilization is measured as a percentage, based on the vertical axis numbers, thus indicating that the B250 M2 database server can handle a much more stringent load. Figure 17. vcpu performance 2011 Cisco EMC VMware. All rights reserved. 46

47 Figure 18. SAP50 Database Server performance (CPU) Storage There are four key metrics on a storage array that are of interest. Front-end (FE) Fibre Channel ports/cpu Cache (Memory slots) Back-end (BE) directors CPU Disks (Fibre Channel) 2011 Cisco EMC VMware. All rights reserved. 47

48 Figure 19. Front-end Fibre Channel ports/cpu Note: The SAP Front-end Fibre Channel ports were less than 15% utilized (Max) for the RTC run Cisco EMC VMware. All rights reserved. 48

49 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 RTC run, the write pending count (approx. 30,000) is much less than the write pending limits (650,000) Cisco EMC VMware. All rights reserved. 49

50 Figure 21. Back end (BE) directors CPU Note: Back End Directors were less than 20% utilized. These are the CPUs of the storage array that move the data from memory slots to disks Cisco EMC VMware. All rights reserved. 50

51 Figure 22. Disks (Fibre Channel) Note: This bar graph shows that although the disks percentage (%) max was utilized, the cache was under-utilized. There was no impact to the host, and host write response time was at memory speeds; not disk speeds Cisco EMC VMware. All rights reserved. 51

52 FICO RUN Application performance comparison Table 8 and Figure 23 illustrate the performance improvements seen when running SAP FICO transactions in the Vblock environment, as compared to the customer environment. Table8. FICO 2nd run 3x6 SAP FICO Transactions Customer Vblock % SAPGUI_FAGLB03_FICO_EXECUTE % SAPGUI_FAGLL03_FICO_EXECUTE % SAPGUI_FBL1N_FICO_EXECUTE % SAPGUI_FBL5N_FICO_EXECUTE % SAPGUI_KE24_FICO_EXECUTE % SAPGUI_KE30_VAR1_FICO_EXECUTE % SAPGUI_KE30_VAR2_FICO_EXECUTE % SAPGUI_ZGRIRAGING_FICO_EXECUTE % SAPGUI_ZPOACCRUAL_FICO_EXECUTE % % 2011 Cisco EMC VMware. All rights reserved. 52

53 Figure 23. SAP FICO transactions running on three virtual application servers Note: The figure above shows the comparison of performance response time between the Vblock and the customer s Test platform. Results show that Vblock was able to process 9 business critical FICO transactions with an improved average response time of 72%. Resource utilization for I/O Figures 24 and 25 show the I/O utilization for the two Fiber Channel connections (fc2/1 and fc2/2) from the 6120 Fabric Interconnect connected to the MDS, which connects to the Symmetrix VMAX Storage Array. Each FC interface is capable of handling up to 4 Gbps of throughput. As you can see, for this FICO run, each interface is only utilizing approximately 90 Mbps and 380 Mbps at peak intervals during the initial ramp up of the LR run, leaving plenty of link capacity to spare as the utilization is under 10% utilized at their highest point Cisco EMC VMware. All rights reserved. 53

54 Figure 24. I/O utilization for Fabric Interconnect interfaces to MDS for fc 2/1 Figure 25. I/O utilization for Fabric Interconnect interfaces to MDS for fc 2/ Cisco EMC VMware. All rights reserved. 54

55 Resource utilization for FCoE Figures 26 and 27 show the aggregate FCoE utilization for the two most highly-utilized FCoE 10 Gbps interfaces (eth1/1 and eth1/6) from the 6120 Fabric Interconnect connected southbound to the I/O Modules for each server in the UCS chassis. For this FICO Run, each interface is only utilizing approximately 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 utilization is under 10% utilized at their highest point. Figure 26. FCoE utilization from chassis to Fabric Interconnect for Ethernet 1/1 Figure 27. FCoE utilization from chassis to Fabric Interconnect for Ethernet 1/ Cisco EMC VMware. All rights reserved. 55

56 CPU In Figure 28, the maximum CPU usage on App Server SAPCL53 on a Vblock during the FICO run was measured at % during a 2-hour period. Figure 28. CPU performance 2011 Cisco EMC VMware. All rights reserved. 56

57 Database Performance was also measured using PerfMon to show the minimal impact on database performance and usage while FICO tests were being run. Notice in Figure 29 how the maximum resource utilization of the database was only % at its peak. Figure 29. Database performance 2011 Cisco EMC VMware. All rights reserved. 57

58 Storage There are four key metrics on a storage array that are of interest: Front-end (FE) Fibre Channel Ports/CPU Cache (Memory Slots) Back end (BE) directors CPU Disks (Fibre Channel) Figure 30. Front end Fibre Channel ports/cpu Note: The FICO run was the heaviest workload of the 3 runs. The directors were 65% utilized Cisco EMC VMware. All rights reserved. 58

59 Figure 31. 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 FICO run, the write pending count (approx 11,000) is much less than the write pending limit (650,000) Cisco EMC VMware. All rights reserved. 59

60 Figure 32. Back end (BE) directors CPU Note: Back end directors percentage was less than 15% utilized. These are the CPUs of the storage array that move the data from memory slots to disks Cisco EMC VMware. All rights reserved. 60

61 Figure 33. Disks (Fibre Channel) Note: This bar graph shows that although the disk s percentage (%) max was utilized, the cache was under-utilized. There was no impact to the host, and host write response time was at memory speeds; not disk speeds. In fact, the disk utilization percentage was less than 70% Cisco EMC VMware. All rights reserved. 61

62 OTC RUN Application performance comparison Table 9 and Figure 34 illustrate the performance improvements seen when running SAP OTC transactions in the Vblock environment, as compared to the customer environment. Table 9 OTC run 3x6 SAP OTC Transactions Customer Vblock % SAPGUI_VA41_OTC_DATA_EXECUTE % SAPGUI_VKM1_VAR2_OTC_EXECUTE % SAPGUI_VKM1_VAR3_OTC_EXECUTE % SAPGUI_ZBACKORDER_VAR1_OTC_EXECUTE % SAPGUI_ZBACKORDER_VAR2_OTC_EXECUTE % SAPGUI_ZDLVSTATUS_OTC_EXECUTE % SAPGUI_ZNOBACKORDER_OTC_EXECUTE % SAPGUI_ZVA14L_OTC_EXECUTE % SAPGUI_ZVASSUMM_VAR1_OTC_EXECUTE % SAPGUI_ZVASSUMM_VAR2_OTC_EXECUTE % SAPGUI_ZVENDORMARK_OTC_EXECUTE % SAPGUI_ZWORKLOAD_MAIN_EXECUTE % SAPGUI_ZWORKLOAD_VAR1_OTC_EXECUTE % SAPGUI_ZWORKLOAD_VAR2_OTC_EXECUTE % % 2011 Cisco EMC VMware. All rights reserved. 62

63 Figure 34. SAP OTC transactions running on three virtual appliccation servers Note: The figure above shows the comparison of performance response time between the Vblock and the customer s Test platform. Results show that Vblock was able to process 14 business critical OTC transactions with an improved average response time of 46% Cisco EMC VMware. All rights reserved. 63

64 I/O Resource utilization Figures 35 and 36 show the I/O utilization for the two Fiber Channel connections (fc2/1 and fc2/2) from the 6120 Fabric Interconnect connected to the MDS which connects to the Symmetrix VMAX Storage Array. Each FC interface is capable of handling up to 4Gbps of throughput. As can be seen in the graphs, for this OTC Run, each interface is only utilizing approximately 8Mbps and 10Mbps at a consistent level during the LR run, leading to plenty of link capacity to spare, as the utilization is under 10%. Figure 35. I/O Utilization for Fabric Inter Connect Interfaces to MDS on fc2/ Cisco EMC VMware. All rights reserved. 64

65 Figure 36. I/O Utilization for Fabric Inter Connect Interfaces to MDS on fc2/ Cisco EMC VMware. All rights reserved. 65

66 FCoE resource utilization Figures 37 and 38 show the aggregate FCoE utilization for the two most highly-utilized FCoE 10Gbps interfaces (eth1/1 and eth1/8) from the 6120 Fabric Interconnect connected southbound to the IO Modules for each server in the UCS chassis. As can be seen in these graphs, for this FICO Run, each interface is only utilizing approximately 5-6Mbps at sustained levels during the LR run, leaving plenty of link capacity to spare, as the utilization is under 10%. Figure 37. FCoE Utilization from Chassis to Fabric Interconnect on Ethernet 1/1 Figure 38. FCoE Utilization from Chassis to Fabric Interconnect on Ethernet 1/ Cisco EMC VMware. All rights reserved. 66

67 vsphere Refer to the RTC run section to view vsphere performance and utilization. CPU Figure 39 shows the CPU usage metrics for the SAPCL54 App Server when an OTC run is executed from 2:39 pm to 3:39 pm. Notice that the maximum CPU usage during this one-hour period was 8.78%, with an average CPU usage of 1.2%. Figure 39. CPU usage metrics Database Performance was also measured using PerfMon to show the minimal impact on database performance and usage while FICO tests were being run. Figure 40 shows how the maximum resource utilization of the database was only % at its peak Cisco EMC VMware. All rights reserved. 67

68 Figure 40. Database performance measurement using PerfMon 2011 Cisco EMC VMware. All rights reserved. 68

69 Storage There are four key metrics on a storage array that are of interest, Front-end (FE) Fibre Channel ports/cpu Cache (Memory Slots) Back End (BE) Directors CPU Disks (Fibre Channel) Figure 41. Front end Fibre Channel ports/cpu Note: The Front-end Fibre Chanel ports were less than 36% utilized Cisco EMC VMware. All rights reserved. 69

70 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 the FICO run, the write pending count (approx 11,000) is much less than the write pending limit (650,000) Cisco EMC VMware. All rights reserved. 70

71 Figure 43. Back end (BE) directors CPU Note: Back end directors were less than 25% utilized. These are the CPUs of the storage array that move the data from memory slots to disks Cisco EMC VMware. All rights reserved. 71

72 Figure 44. Disks (Fibre Channel) Note: Disk utilization percentage was 50% max but did not affect the write response times since the write pending limit was not reached Cisco EMC VMware. All rights reserved. 72