Hadoop with Enhanced Networking on AWS

Start Free Trial
March 13, 2015 by Updated January 5th, 2024

Introduction

At Qubole, many of our customers run their Hadoop clusters on AWS EC2 instances. Each of these instances is a Linux guest on a Xen hypervisor. Traditionally each guest’s network traffic goes through the hypervisor, which adds a little bit of overhead to the bandwidth. EC2 now supports Single Root I/O Virtualization (called Enhanced Networking in AWS terminology) on some of the new instance types, wherein each physical ethernet NIC virtualizes itself as multiple independent PCIe Ethernet NICs, each of which can be assigned to a Xen guest.

Many resources on the web (such as this) have documented improvements in bandwidth and latency when using enhanced networking. This was mentioned by our helpful partner engineers at AWS as another one of the low-hanging fruits that we should investigate. Hadoop is very network I/O intensive – large amounts of data are transferred between nodes as well as between S3 and the nodes – hence it stands to reason that Hadoop workloads would benefit from this change. However – as someone once said, following recommendations based on someone else’s benchmarks is like taking someone else’s prescribed medicine – so we set out to benchmark our Hadoop offering against instances with Enhanced Networking. This post describes data obtained from this study.

Benchmark Setup

Enabling enhanced networking required us to make the following changes to our machines:

  • Upgrade the Linux kernel to 3.14 from 2.6.
  • Use HVM AMIs for all supported instance types, since enhanced networking is only supported on the HVM AMIs

We designed our test setup to understand the performance difference due to each of these factors: the kernel upgrade, movement from PVM to HVM AMIs, and using Enhanced Networking itself.

  1. We used the traditional Hadoop Terasort and testDFSIO benchmarks on clusters ranging in size from 5-20 nodes. Qubole also offers Apache Spark and Presto as a Service – and ideally, we would have liked to benchmark them against these upgrades as well (and hopefully will be able to do so in the future).
  2. There have been some improvements in the KVM and Xen hypervisor stacks in recent versions of the Linux kernel. To exclude performance improvements due to these changes, we tested the PV AMI with both the 2.6 and 3.14 kernels.
  3. HVM AMIs are supposed to be more performant than PV AMIs in general, and to exclude the possibility of this polluting the benchmarks, we tested PV against HVM AMIs (with both on the 3.14 kernel)
  4. Finally, we ran the benchmarks for clusters of similar configurations with and without Enhanced Networking enabled.

Thus we can say with reasonable confidence that the benchmarks we obtained for Enhanced Networking are exclusive of benefits obtained by the collateral changes that we made to support it. For brevity, not all the benchmarks between different instance types are listed here. Only a few are listed – sufficient to demonstrate the benefits of the upgrades.

Benchmark Results

PV kernel upgrade

<!–

200GB TeraSort, with 5 m1.xlarge slaves
Benchmark2.6 kernel (time in seconds)3.14 kernel (time in seconds)Change (%)
Teragen1144780-31.82%
Terasort24642359-4.26%

–>

With the new 3.14 kernel, we saw ~32% improvement in TeraGen and ~5% improvement in TeraSort times.

pv_kernel_upgrade

testDFSIO, 20 files of 10GB each, with 5 m1.xlarge slaves
Benchmark2.6 kernel3.14 kernelChange (%)
testDFSIO Write
Throughput MB/sec14.821521827914516.26289952861989.72%
Average IO rate MB/sec15.480115890502916.4341754913336.16%
Time taken (s)901.817725.172-19.59%
testDFSIO Read
Throughput MB/sec6202.127337170.51484315.61%
Average IO rate MB/sec7031.7607428717.2187523.97%
Time taken (s)24.723.287-5.72%

 

PV vs HVM virtualization

In these tests, both clusters were running instances with the new 3.14 Linux kernel. HVM AMIs gave us ~10.5% improvement in TeraGen and ~13% improvement in TeraSort times as compared to their PV counterparts.

<!–

100GB TeraSort, with 5 m3.2xlarge slaves
BenchmarkPV AMI (time in seconds)HVM AMI (time in seconds)Change (%)
Teragen585524-10.43%
Terasort19021658-12.83%

–>
pv_vs_hvm

testDFSIO, 20 files of 5GB each, with 5 m3.2xlarge slaves
BenchmarkPV AMIHVM AMIChange (%)
testDFSIO Write
Throughput MB/sec17.5338930219.3177063410.17%
Average IO rate MB/sec18.3333568620.042242059.32%
Time taken (s)376.843348.93-7.41%
testDFSIO Read
Throughput MB/sec3296.3048423389.1411922.82%
Average IO rate MB/sec4763.1088875134.7314457.80%
Time taken (s)22.51320.492-8.98%

 

Enhanced networking

Enhanced networking only works in VPC environments, so these tests were performed by running one cluster in a VPC, and another in EC2 classic. Also in our testing, we found that the maximum benefit of this feature was obtained in instances that support 10Gb ethernet (c3.8xlarge, r3.8xlarge, and i2.8xlarge). Hence we are capturing the benchmark results against c3.8xlarge instance types here:
<!–

1TB TeraSort, with 5 c3.8xlarge slaves
BenchmarkCluster in EC2-Classic (time in seconds)Cluster in VPC (time in seconds)Change (%)
Teragen16551171-29.24%
Terasort37122953-20.45%
–>
We found that Enhanced Networking gave us an impressive ~29.2% improvement in TeraGen and ~20.45% reduction in TeraSort times.
enhanced_networking
testDFSIO, 160 files of 3GB each, with 5 c3.8xlarge slaves
BenchmarkCluster in EC2-ClassicCluster in VPCChange (%)
testDFSIO Write
Throughput MB/sec11.307684426.64146881135.60%
Average IO rate MB/sec14.8156204226.9926382.19%
Time taken (s)562.802152.548-72.89%
testDFSIO Read
Throughput MB/sec2086.8549014705.882353125.50%
Average IO rate MB/sec3664.1074225546.87402351.38%
Time taken (s)26.44718.444-30.26%

 

Conclusion

Based on this study we concluded that:

  • The upgraded Linux kernel benefits both PV and HVM AMIs. We have, therefore, upgraded the kernel on all our AMIs.
  • Where supported, the HVM AMI is more performant than the PV AMI for Hadoop workloads. We now use the HVM AMI for m3 and c3-type instances as well. These were earlier using PV AMIs.
  • Enhanced networking offers significant performance benefits for Hadoop workloads on some supported instance types

In other cases – the benchmarks indicated that there were no significant performance improvements:

  • Enhanced networking on instance types that do not support 10Gb ethernet. On these, the improvement in TeraGen/Sort was not significant. Enhanced networking is enabled on these instance types as well, so it is possible that your particular workload may see some benefits.
  • Placement groups – although placement groups are supposed to improve network performance further by offering full-bisection bandwidth and low-latency connections between instances, we did not observe significant benefits to using this over and above-enhanced networking. One possible reason for this could be that with smaller cluster sizes, the probability of the nodes being co-located is pretty high anyway.

Enhanced Networking upgrades in QDS

For users of QDS – if you’re using one of the instance types supporting enhanced networking in a VPC for your cluster slaves – good news, you’re already using all these improvements in your Qubole cluster! Note that machine images for all cluster types (Hadoop, Spark, and Presto) have been upgraded. For others:

  1. if you’re using one of the older generation instance types that only support PV AMIs, you still get the benefit of the upgraded Linux kernel
  2. if you’re using an instance type that supports enhanced networking, but your cluster is not in a VPC, you can easily configure your cluster to run in a VPC to avail the benefits of enhanced networking.
  3. if you’d like to switch to a newer instance type to use enhanced networking, we recommend you test your workload (partially or completely) against a new cluster before you make the switch. Your Mileage May Vary with respect to the performance benefits.

If you need any help with making any of the above changes, please contact us and we’d be glad to help!

Start Free Trial
Read Bridging HDFS2 with HDFS1