Hadoop Rack Considerations - dummies

Hadoop Rack Considerations

By Dirk deRoos

A core principle of Hadoop is scaling out with additional slave nodes to meet increasing data-storage and -processing demands. In a scale-out model, you must carefully consider cluster design because dozens, and even hundreds, of slave nodes will ultimately need to be racked, powered, networked, and cooled.

Server form factors

One of the first choices that IT architects will face when designing a Hadoop cluster is which of the following two form factors to use for Hadoop nodes:

  • Blade server: Designed for maximum density, you can cram as many of these babies into one rack as possible. Blade servers fit into blade enclosures, which have many standard server components, like dedicated storage, networking, power, and cooling. These components are shared among the blade servers, which means that each individual blade server can be much smaller.

    Blade servers are an appealing choice on the surface because you could take a standard rack and deploy between 40 and 50 of these blade servers. The problem with using blades for Hadoop deployments is that they rely on certain shared components, which isn’t in line with Hadoop’s shared-nothing architecture, where each of the slave nodes are self-contained and have their own dedicated resources.

    More importantly, blades have little room for locally attached storage, often having no more than two or three drive bays. This is a non-starter for Hadoop, since slave nodes need much more dedicated storage capacity.

  • Rack server: Complete servers with no shared components and room for hardware expansion, rack servers are the true choice for Hadoop because they’re nicely self-contained. A rack server that’s appropriately configured for being a Hadoop slave node typically occupies two RU, so you can fit 20 of them in a standard rack.

Cost of ownership

When choosing and designing a slave node, your most important considerations are typically the initial procurement costs and the storage volume. However, the cost of ownership is also important. It’s a fine balancing act, however, because choices affecting procurement cost, power consumption, cooling, hardware performance, and density are often in opposition. In the name of helping you make good choices, here’s some (quite specific) advice:

  • Reserve redundant power supplies for the master nodes. Having redundant power supplies for slave nodes is overkill — a power supply failure in a slave node wouldn’t greatly affect the cluster. However, having redundant power supplies on all slave nodes would increase power consumption and generate more heat.

  • Choose middle-of-the-road clock speeds for slave node CPUs. CPUs with higher clock speeds not only cost more but also use more power and generate far more heat.

  • Choose rack servers that are designed for Hadoop. With the rising popularity of Hadoop, all major hardware vendors now offer rack servers that are ideal slave nodes, with 12 to 20 drive bays for locally attached storage.

    Rack servers designed to work as Hadoop slave nodes are typically too big to fit into a form factor of one RU, but taking up two RUs can result in wasted space. For the more efficient use of space, certain hardware vendors have released rack servers that cram multiple slave nodes into a single chassis.

    As an example, in this compressed form, a standard rack can have as many as 27 slave nodes (even with network switches), where each slave node has room for 15 disk drives for HDFS. The upshot of this arrangement is much higher density and better use of space in the data center.