Summary of the content on the page No. 1
W H I T E P A P E R
VMware vSphere™ 4 Fault Tolerance:
Architecture and Performance
Summary of the content on the page No. 2
VMware white paper Table of Contents 1. VMware Fault Tolerance a rchitecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Deterministic r ecord/r eplay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Fault tolerance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Summary of the content on the page No. 3
VMware white paper VMware® Fault Tolerance (FT) provides continuous availability to virtual machines, eliminating downtime and disruption — even in the event of a complete host failure. This whitepaper gives a brief description of the VMware FT architecture and discusses the performance implication of this feature with data from a wide variety of workloads. 1. VMware Fault Tolerance a rchitecture The technology behind VMware Fault Tolerance is called VMware® vLockstep. The following sections
Summary of the content on the page No. 4
VMware VMware VMware white paper Figure 2. High Level Architecture of VMware Fault Tolerance Primary Secondary APP APP OS OS FT Logging Tra c ACKs Record Replay Client Shared Storage The communication channel between the primary and the secondary host is established by the hypervisor using a standard TCP/IP socket connection and the traffic flowing between them is called FT logging traffic. By default, incoming network traffic and disk reads at the primary virtual machine are captured and sen
Summary of the content on the page No. 5
VMware white paper 2. Performance a spects and Best Practice recommendations This section describes the performance aspects of Fault Tolerance with best practices recommendations to maximize performance. For operational best practices please refer to the VMware Fault t olerance r ecommendations and Considerations on VMware vSphere 4 w hite paper. 2.1. FT Operations: Turning On and enabling There are two types of FT operations that can be performed on a virtual machine: Turning FT on or off, an
Summary of the content on the page No. 6
VMware white paper To ensure that the secondary virtual machine runs as fast as the primary, it is recommended that: • T he hosts in the FT clust er ar e homogenous , with similar CPU mak e , model , and fr equenc y . T he CPU fr equenc y diff er ence should not exceed 400 MHz. • B oth the pr imar y and secondar y hosts use the same po w er management polic y . • CPU r eser vation is set t o full f or cases wher e the secondar y host could be o v
Summary of the content on the page No. 7
VMware white paper It is recommended that FT primary virtual machines be distributed across multiple hosts and, as a general rule of thumb, the number of FT virtual machines be limited to four per host. In addition to avoiding the possibility of saturating the network link, it also reduces the number of simultaneous live migrations required to create new secondary virtual machines in the event of a host failure. 2.8. DrS and VMotion DRS takes into account the additional CPU and memory resourc
Summary of the content on the page No. 8
VMware white paper Figure 4. SPECjbb2005 Performance FT tra c: SPECjbb2005 1.4 Mbits/sec 120 100 80 60 FT Disabled FT Enabled 40 20 0 RHEL 5 64-bit, 4GB 3.2. Kernel Compile This experiment shows the time taken to do kernel compile, which is both CPU and MMU intensive workload due to forking of many parallel processes. As with the previous experiment, CPU is 100 percent utilized and thus FT performance is dependent on how well the secondary can keep pace with the primary. This workload does so
Summary of the content on the page No. 9
VMware white paper 3.3. Netperf Throughput Netper f is a micr o -benchmar k that measur es the thr oughput of sending and r eceiving net w or k pack ets . I n this exper iment netper f was configured so packets could be sent continuously without having to wait for acknowledgements. Since all the receive traffic needs to be recorded and then transmitted to the secondary, netperf Rx represents a workload with significant FT logging traffic. As shown inFigure 6, with FT enabled, the virtual mac
Summary of the content on the page No. 10
VMware white paper Figure 7. Netperf Latency Comparison FT tra c Netperf - latency sensitive case Rx: 500 Mbits/sec 1000 Tx: 36 Mbits/sec 900 800 700 600 FT Disabled 500 FT Enabled 400 300 200 100 0 Receives Transmits 3.5. Filebench r andom Disk read/w rite Filebench is a benchmark designed to simulate different I/O workload profiles. In this experiment, filebench was used to generate random I/Os using 200 w or k er thr eads . T his w or k load saturat es a vailable disk bandwidth f or the g
Summary of the content on the page No. 11
VMware white paper 3.6. Oracle 11g I n this exper iment, an Oracle 11g database was dr iv en using the S wingbench Or der Entr y OL TP ( online transac tion pr ocessing) workload. This workload has a mixture of CPU, memory, disk, and network resource requirements. 80 simultaneous database sessions w er e used in this exper iment. Enabling FT had neglig ible impac t on thr oughput as w ell as lat enc y of transac tions . Figure 9. Oracle 11g Database Performance (throughput) FT tra c: Oracle
Summary of the content on the page No. 12
VMware white paper 3.7. Microsoft SQL Server 2005 In this experiment, the DVD Store benchmark was used to drive the Microsoft SQL Server® 2005 database. This benchmark simulates online transaction processing of a DVD store. Sixteen simultaneous user sessions were used to drive the workload. As with the previous benchmark, this workload has a mixture of CPU, memory, disk, and networking resource requirements. Microsoft SQL Server however issues many RDTSC instructions, which read the processo
Summary of the content on the page No. 13
VMware white paper 3.8. Microsoft exchange Server 2007 I n this exper iment, the L oadgen w or k load was used t o generat e load against M icr osof t Ex change S er v er 2007. A hea v y user pr ofile with 1600 users was used. This benchmark measures latency of operations as seen from the client machine. The performance charts belo w r epor t both a v erage lat enc y and 95th per centile lat enc y f or var ious Ex change operations . T he generally accept ed thr eshold f or acceptable latenc
Summary of the content on the page No. 14
VMware white paper 4. VMware Fault Tolerance Performance Summary All Fault Tolerance solutions rely on redundancy. Additional CPU and memory resources are required to mirror the execution of a running virtual machine instance. Also, some amount of CPU is required for recording, transferring, and replaying log events. The amount of CPU required is mostly dependent on incoming I/O. If the primary virtual machine is constantly busy and resource constraints at the secondary prohibit catching up,
Summary of the content on the page No. 15
VMware VMware VMware white paper a ppendix a: Benchmark Setup Primary Secondary Cross cable Intel Xeon E5440 Intel Xeon E5440 2.8GHz – 8 CPUs 2.8GHz – 8 CPUs APP APP 8GB of RAM 8GB of RAM OS OS Intel Optin XF SR Intel Optin XF SR 10GB NIC 10GB NIC Intel NC364T ESXi 4.0 ESXi 4.0 Quadport Gigabit EMC Clariion CX3-20 Flare OS 03.2.6.020.5.011 Client AMD Operteron Processor 275 – 4 CPUs 2.21GHz 8GB of RAM Storage Array S yst em: Clar iiON CX3-20 FLARE OS: 03.26.020.5.011 L UNs: RAID 5 L UNs (6 disk
Summary of the content on the page No. 16
VMware white paper a ppendix B: workload Details SPECjbb2005 V ir tual machine configuration: 1 vCPU , 4GB RA M, Enhanced VMXNE T vir tual NIC, LSI L og ic vir tual SCSI adapt er OS v ersion: RHEL5.1, x64 J a va V ersion: JR ock it R27.4.0, J a va 1.6.0_22 Benchmark parameters: No of war ehouses: T w o JVM P aramet ers: - X X agg r essiv e - Xgc:parallel - X X compac tratio8 - X Xminblocksiz e32k - X Xlar geObjec tLimit=4k - Xmx1024m - Xms1024m Note: Sco
Summary of the content on the page No. 17
VMware white paper Swingbench configuration: Swingbench version: 2.2, Calling Circle Database No of or ders: 23550492 No of C ust omers: 864967 Runtime: 30 mins ODBC driver: ojdbc6.jar Driver Type: Thin No of Users: 80 Pooled: 1 LogonDelay: 0 Transaction MinDelay: 50 Transaction MaxDelay: 250 QueryTimeout: 60 W or k load W eightage: Ne wC ust omerP r ocess – 20, Br o wseP r oduc ts – 50, P r ocessOr ders – 10, Br o wseAndUpdat eOr ders – 50 Note: Database was restored fr
Summary of the content on the page No. 18
VMware white paper Exchange 2007 — Loadgen V ir tual machine configuration: 1 vCPU , 4GB RA M, Enhanced VMXNE T vir tual NIC, LSI L og ic vir tual SCSI adapt er OS v ersion: W indo ws S er v er 2003 R2, Datacent er E dition, 64-bit Ex change v ersion: Ex change S er v er 2007 SP1, 64-bit v ersion (08.01.0240.006) Ex change configuration: AD , M ail Hub , IIS and all other Ex change components installed on the same vir tual machine Ex change Database: T w o 150GB databases , each hosting 800 u
Summary of the content on the page No. 19
VMware, Inc. 3401 Hillview Ave Palo Alto CA 94304 USA Tel 877-486-9273 Fax 650-427-5001 www.vmware.com Copyright © 2009 VMware, Inc. All rights reserved. This product is protected by U.S. and international copyright and intellectual property laws. VMware products are covered by one or more patents listed at http://www.vmware.com/go/patents. VMware is a registered trademark or trademark of VMware, Inc. in the United States and/or other jurisdictions. All other marks and names mentio
