In this special guest feature, Tom Lyon, Chief Scientist at DriveScale, describes how to run demanding analytics applications and/or 1000+ node Hadoop workloads on commodity servers and storage. Tom is a computing systems architect, a serial entrepreneur and a kernel hacker. He most recently co-founded DriveScale, a company that is pioneering flexible, scale-out computing for the enterprise using standard servers and commodity storage. He received a B.S. in Electrical Engineering and Computer Science from Princeton University. Tom was also a founder at Nuova Systems (sold to Cisco) and Ipsilon Networks (sold to Nokia). Additionally, as employee #8 at Sun Microsystems, Tom made seminal contributions to the UNIX kernel, created the SunLink product family, and was one of the NFS and SPARC architects.
So, you’ve had your Hadoop cluster for a while. You’ve got maybe 50 to 100 nodes running stably, you’ve got some mastery of the analytics frameworks – whether Spark or Flink or good old Map-Reduce. You’ve been able to demonstrate real business value from your cluster and you’re ready to take it to a whole new level with lots more data and a lot more applications and users. The hardware for your cluster was probably not a big concern as you dove into Hadoop, so you went with the typical racks of commodity servers, each with 12 or 24 hard drives. It works, so why think about different hardware?
Well, because as your cluster size approaches many hundreds of nodes, it will certainly be the biggest cluster in your data center, and may even become the majority of your compute infrastructure. At this scale, inefficiencies caused by poorly balanced resources can add up to a lot of wasted time, money, power, heat, and space!
Bend It or Break It
Even if you think your CPU and storage are well balanced today, you can bet they won’t be as applications and frameworks evolve, data gets bigger, and CPUs get faster. The CPU you buy next year will be twice as fast as last years’; the disks will still be slow but have enormous capacity. There’s just no predicting the correct balance between CPU and storage. What you need is flexibility.
That flexibility is achieved by disaggregating/separating the disk from the CPU nodes. But beware traditional NAS and SAN solutions – they are far from “commodity” hardware and will blow your budget to smithereens while struggling to achieve the performance levels that Hadoop needs. Look for solutions with rack-scale architectures that can maximize your flexibility while preserving the high performance and low cost needed for Hadoop. The whole Big Data movement is enabled by very cheap storage, so don’t get locked into a traditional “gold-plated” storage solution.
Go Big!
Once storage is removed from the CPU nodes, you have a much broader choice of CPU/memory combinations. Consider the “classic” Hadoop node of 2013/4 – 12 CPU cores with about 64GB of memory. Today, you can easily afford 36 to 40 core nodes with 512GB of memory (and the cores and memory are both a lot faster). Even if you have a traditional Map/Reduce application which is I/O limited on smaller CPUs, moving to bigger, beefier CPU nodes can remove a lot of communication and serialization overhead. Spark and other newer frameworks can vastly benefit from larger amount of memory in CPUs because a few big caches are more efficient than the same amount of cache spread over more nodes.
And don’t skimp on networking! Anything less than 10Gbps is like breathing through a straw for today’s servers, and if you’ve separated your disks than that traffic is on the network as well. Even if you can’t control your network backbone bandwidth, adding bandwidth “in the rack” can help Hadoop a lot. Today, right now, you can get complete 25Gbps Ethernet solutions from vendors like Dell that’ll get you 2 25GbE ports for each server at a very affordable price.
So look before you leap into a large scale Hadoop project, and make sure your hardware plans take into account today’s technologies, not just what people were successful with in previous years.
This article was originally published on www.insidebigdata.com and can be viewed in full
Archive
- October 2024(19)
- September 2024(94)
- August 2024(100)
- July 2024(99)
- June 2024(126)
- May 2024(155)
- April 2024(123)
- March 2024(112)
- February 2024(109)
- January 2024(95)
- December 2023(56)
- November 2023(86)
- October 2023(97)
- September 2023(89)
- August 2023(101)
- July 2023(104)
- June 2023(113)
- May 2023(103)
- April 2023(93)
- March 2023(129)
- February 2023(77)
- January 2023(91)
- December 2022(90)
- November 2022(125)
- October 2022(117)
- September 2022(137)
- August 2022(119)
- July 2022(99)
- June 2022(128)
- May 2022(112)
- April 2022(108)
- March 2022(121)
- February 2022(93)
- January 2022(110)
- December 2021(92)
- November 2021(107)
- October 2021(101)
- September 2021(81)
- August 2021(74)
- July 2021(78)
- June 2021(92)
- May 2021(67)
- April 2021(79)
- March 2021(79)
- February 2021(58)
- January 2021(55)
- December 2020(56)
- November 2020(59)
- October 2020(78)
- September 2020(72)
- August 2020(64)
- July 2020(71)
- June 2020(74)
- May 2020(50)
- April 2020(71)
- March 2020(71)
- February 2020(58)
- January 2020(62)
- December 2019(57)
- November 2019(64)
- October 2019(25)
- September 2019(24)
- August 2019(14)
- July 2019(23)
- June 2019(54)
- May 2019(82)
- April 2019(76)
- March 2019(71)
- February 2019(67)
- January 2019(75)
- December 2018(44)
- November 2018(47)
- October 2018(74)
- September 2018(54)
- August 2018(61)
- July 2018(72)
- June 2018(62)
- May 2018(62)
- April 2018(73)
- March 2018(76)
- February 2018(8)
- January 2018(7)
- December 2017(6)
- November 2017(8)
- October 2017(3)
- September 2017(4)
- August 2017(4)
- July 2017(2)
- June 2017(5)
- May 2017(6)
- April 2017(11)
- March 2017(8)
- February 2017(16)
- January 2017(10)
- December 2016(12)
- November 2016(20)
- October 2016(7)
- September 2016(102)
- August 2016(168)
- July 2016(141)
- June 2016(149)
- May 2016(117)
- April 2016(59)
- March 2016(85)
- February 2016(153)
- December 2015(150)