Riverbed Stingray Traffic Manager VMware vsphere 4 Performance on Cisco Unified Computing System WHITE PAPER

Transcription

1 Riverbed Stingray Traffic Manager VMware vsphere 4 Performance on Cisco Unified Computing System WHITE PAPER

2 Riverbed Stingray Traffic Manager VMware vsphere 4 Performance on Cisco Unified Computing System Table of Content Introduction Test Setup... 3 System Under Test Benchmarks Results Analysis Comparison to Previous Tests Riverbed Technology. All rights reserved. 2

3 Riverbed Stingray Traffic Manager VMware vsphere 4 Performance on Cisco Unified Computing System INTRODUCTION This document details the performance figures obtained by the Riverbed Stingray Traffic Manager running on VMware vsphere 4.0 on the Cisco Unified Computing System (UCS) and outlines the methods used to achieve these performance figures. This testing follows a previous test conducted with Cisco UCS blade running on a previous generation of Intel Xeon processors. The results from these two sets of tests will be compared at the end of this document. Test Setup The system under test utilized a Cisco B200-M2 blade server with two 64-bit six-core Intel Xeon X5680 CPUs ( Westmere-EP ) at 3.33 GHz with 48 GB of RAM. The number of load-generating clients and web servers depended on the tests being run. For some tests, two load generating clients and four web servers were used. For other tests, three load generating clients and three web servers were used. All load generating clients and web servers utilized Cisco B200-M1 blade servers with two 64-bit quadcore Intel Xeon X5570 CPUs ( Nehalem-EP ) at 2.93 GHz and 48 GB of RAM. Two load generator clients and the system under test were in one UCS chassis, while four web servers were in a separate chassis. When a third load generating client was needed, one of the web servers was used. All systems had dual-ported Cisco UCS M81KR VIC adapters, with one port each on the A and B UCS interconnects. All interfaces on the A interconnect were on a separate subnet from those on the B interconnect. RedHat Enterprise Linux 5.4 was the operating system used for all machines. Zeus Traffic Manager was running on the system under test and load balancing the requests across Zeus Web Servers. The requests were generated by a program called Zeusbench, a high-performance, vendor agnostic, HTTP benchmarking tool that is included with Stingray Traffic Manager. Zeusbench reported the benchmarking results obtained on each of the clients. These results were then collated to ascertain the overall performance of the system under test. System Under Test Virtual Environments The performance figures for the various virtual configurations were obtained using the 64-bit build of Stingray Traffic Manager VA 6.0r7 installed on a Redhat 5.4 virtual machine on vsphere 4.1. When obtaining performance figures, Stingray Traffic Manager instances were the only virtual machines installed on the vsphere server. The virtual machines were each allocated 1 GB of RAM. One, two, or three vcpus were allocated to each virtual machine depending on the test. The VMware VMDirectPath capabilities of the Intel Xeon Architecture coupled with Cisco UCS M81KR VIC Adapter capability to instantiate virtual pci-e devices (in this instance multiple virtual network adapters), which were utilized so that the network traffic bypassed the VMware Hypervisor and went directly from the hardware to the VM. The driver used was the VMXNet 3 driver provided by VMware. For all tests, each Stingray Traffic Manager instance utilized a single 10G uplink on the network adapter. Stingray Traffic Manager instances were evenly divided between the A and B UCS interconnects. The following Linux tunings were applied to each Stingray Traffic Manager instance: echo " " > /proc/sys/net/ipv4/ip_local_port_range echo 0 > /proc/sys/net/ipv4/tcp_syncookies echo 8192 > /proc/sys/net/ipv4/tcp_max_syn_backlog echo 1024 > /proc/sys/net/core/somaxconn echo > /proc/sys/net/ipv4/tcp_max_tw_buckets echo " " > /proc/sys/net/ipv4/tcp_mem echo > /proc/sys/fs/file-max echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse echo 1 > /proc/sys/net/ipv4/tcp_tw_recycle 2011 Riverbed Technology. All rights reserved. 3

4 Riverbed Stingray Traffic Manager VMware vsphere 4 Performance on Cisco Unified Computing System The following diagrams describe the different virtual machine environments: Diagram A: 2 VMs 2011 Riverbed Technology. All rights reserved. 4

11 Riverbed Stingray Traffic Manager VMware vsphere 4 Performance on Cisco Unified Computing System Benchmarks The intent of the benchmarks was to obtain performance figures with 2, 4, 8, 12, 16, and bit virtual machines with varying numbers of virtual CPUs utilizing the virtualization optimized Cisco UCS M81KR VIC Adapter. These figures could then be compared to discover how performance is affected by scaling the number of virtual machines and virtual CPUs. The benchmarks conducted consisted of the following tests: HTTP connections per second: The rate at which Stingray Traffic Manager can process new HTTP connections. Clients send a series of HTTP requests, each on a new connection. Stingray Traffic Manager parses the requests and forwards them on to a web server using an established keepalive connection. The web server sends back a response for each request. HTTP requests per second: The rate at which Stingray Traffic Manager can handle HTTP requests. Each client sends its requests down an existing keepalive connection. Stingray Traffic Manager processes each request and forwards it on to a web server over another keepalive connection. The web server responds with a zero-sized file. HTTP 2K requests per second: The rate at which Stingray Traffic Manager can handle requests for a 2 KB file. HTTP 8K requests per second: The rate at which Stingray Traffic Manager can handle requests for an 8 KB file. HTTP throughput: The throughput that Stingray Traffic Manager can sustain when serving large files via HTTP. The methodology used for the HTTP requests per second benchmark is used here, however the files requested are 1 MB in size. SSL connections per second: The rate at which Stingray Traffic Manager can decrypt new SSL connections. Clients send a series of HTTPS requests, each on a new connection, for a zero-sized file. SSL session IDs are not re-used, so each connection requires a full SSL handshake bit RC-4 encryption is used. SSL throughput: The throughput Stingray Traffic Manager can sustain while performing SSL decryption. Each client sends its requests on an existing keepalive connection and SSL session IDs are re-used. The test measures the performance of the cipher used to encrypt and decrypt the data passed along the SSL connection Riverbed Technology. All rights reserved. 11

12 Traffic Valuation and Prioritization with Riverbed Traffic Manager Results The following table presents the test results of each of the virtual machine configurations running Stingray Traffic Manager: Test Name 2 VM 2 vcpu/vm 4 VM 2 vcpu/vm 4 VM 3 vcpu/vm 6 VM 2 vcpu/vm 8 VM 1 vcpu/vm HTTP conn/s 114, , , , ,000 HTTP req/s 266, , , , ,000 HTTP 2K req/s 202, , , , ,000 HTTP 8K req/s 148, , , , ,000 HTTP throughput (Gbits) SSL conn/s 10,600 20,700 31,300 30,700 20,100 SSL throughput (Gbits) Test Name 8 VM 2 vcpu/vm 12 VM 1 vcpu/vm 12 VM 2 vcpu/vm 16 VM 1 vcpu/vm 24 VM 1 vcpu/vm HTTP conn/s 300, , , , ,000 HTTP req/s 559, , , , ,000 HTTP 2K req/s 398, , , , ,000 HTTP 8K req/s 248, , , , ,000 HTTP throughput (Gbits) SSL conn/s 30,200 28,300 29,700 28,000 27,900 SSL throughput (Gbits) Riverbed Technology. All rights reserved. 12

13 Traffic Valuation and Prioritization with Riverbed Traffic Manager The following charts compare the aggregate performance of each virtual machine configuration, ordered by the number of virtual machines: 2011 Riverbed Technology. All rights reserved. 13

14 Traffic Valuation and Prioritization with Riverbed Traffic Manager The following charts compare the aggregate performance of each virtual machine configuration, ordered by the number of physical cores being utilized: 2011 Riverbed Technology. All rights reserved. 14

15 Traffic Valuation and Prioritization with Riverbed Traffic Manager Analysis The charts presented above show the difference in performance between benchmarks for each virtual machine configuration. The configurations vary by the number of virtual machines and the number of virtual CPUs configured for each virtual machine. The results for HTTP connections/second showed outstanding performance in the virtual environment. These tests are not bandwidth dependent, so as expected, the results improved as the number of physical cores used increased until all 12 cores were being utilized. The peak result was found when using 4 VMs with 3 vcpus, which was slightly higher than the result when using 6 VMs with 2 vcpus. As the number of virtual machines increased to the point where there were more vcpus than physical cores, the results began to decrease due to CPU oversubscription overhead. The results for HTTP requests/second also showed outstanding performance in the virtual environment. Again, peak performance was found using either 4 VMs with 3 vcpus, or 6 VMs with 2 vcpus. We note a measurable degradation in performance at 24 VMs, likely due to the combination of the overhead of context switching between virtual machines, the impact on the memory hierarchy performance, and the impact on having de-scheduled virtual machines affecting the timing of the network flows at the TCP level. Nevertheless, the performance levels remain acceptable in this configuration, thereby validating the scenarios where Riverbed appliances are deployed for maximum density to scale-out and scale-down. Note that the HTTP 8K request/second test is bandwidth-limited when using a 10G adapter, explaining why the results are fairly close between the various configurations. The results obtained for HTTP throughput show consistent performance between 19 to 19.3G as the number of virtual machines was increased from two to eight. A slight drop occurred when using 12 and 16 virtual machines, and then a further slight drop when using 24 virtual machines. Achieving 19G+ from a 20G adapter in a virtualized environment is an outstanding result. SSL processing is CPU intensive, so as expected, the results obtained for the SSL connections/second test and the SSL throughput test improve as the number of physical cores in use increases. A peak was again achieved when using 4 VMs with 3 vcpus or 6 VMs with 2 vcpus, but the results stayed consistently high as the number of virtual machines increased, with some drop-off Riverbed Technology. All rights reserved. 15

16 Traffic Valuation and Prioritization with Riverbed Traffic Manager Comparison with Previous Test In November 2009, Zeus (which is now a part of Riverbed) released a white paper entitled: Zeus Traffic Manager VMware vsphere 4 Performance on Cisco Unified Computing System. This white paper details a set of tests undertaken that were similar to the tests detailed in the previous white paper, so it is interesting to compare the results. The major difference between the two sets of tests is that in the original test the System under test was an 8-core blade running on Intel Xeon 2.93 GHz processors, whereas the more recent testing uses a 12-core blade running on Intel Xeon 3.33 GHz processors. For more details on the previous tests, please refer to the previous white paper. The charts below compare the results from the previous and current set of tests. From this comparison, it can be seen that not only can higher peak results be achieved with the 12-core blade, but it can clearly handle larger numbers of virtual machines more efficiently Riverbed Technology. All rights reserved. 16

20 Traffic Valuation and Prioritization with Riverbed Traffic Manager About Riverbed Riverbed delivers performance for the globally connected enterprise. With Riverbed, enterprises can successfully and intelligently implement strategic initiatives such as virtualization, consolidation, cloud computing, and disaster recovery without fear of compromising performance. By giving enterprises the platform they need to understand, optimize and consolidate their IT, Riverbed helps enterprises to build a fast, fluid and dynamic IT architecture that aligns with the business needs of the organization. Additional information about Riverbed (NASDAQ: RVBD) is available at Riverbed Technology, Inc. 199 Fremont Street San Francisco, CA Tel: (415) Riverbed Technology Ltd. The Jeffreys Building Cowley Road Cambridge CB4 0WS United Kingdom Tel: +44 (0) Riverbed Technology Pte. Ltd. 391A Orchard Road #22-06/10 Ngee Ann City Tower A Singapore Tel: Riverbed Technology K.K. Shiba-Koen Plaza Building 9F 3-6-9, Shiba, Minato-ku Tokyo, Japan Tel: Riverbed Technology. All rights reserved. 20