HPCwire: Does Your Cluster Scale?

The Leading Source for Global News and Information Covering the Ecosystem of High Productivity Computing

HPCwire >> Features

September 22, 2006

Does Your Cluster Scale?

by Benoit Marchand, CEO, eXludus Technologies Inc.

Introduction

This article will discuss both the hidden and painfully obvious scaling inefficiencies inherent in current technology commodity cluster and Grid computing with respect to data movement. It will also discuss the latest advances in parallel file serving technology and how these techniques can be utilized with current network topologies, file servers and unmodified applications to deliver throughput performance speed-ups of order 2X to 9X on certain workloads.

Commodity Clusters: The Promise and the Reality

IDC reported that in 2005 clusters represented about 50 percent of high performance and technical computing systems sales. Cluster sales have been growing very rapidly, driven by the desire to lower TCO for computationally intensive workloads.

"I think there is a world market for maybe five computers."
- Thomas Watson, Chairman of IBM, 1943

Perhaps you have more than five computers in your cluster. Using commodity components to build high-throughput clusters makes tremendous sense for delivering affordable processing power. In theory if your application is highly parallel, the run-time should reduce almost linearly as additional processing nodes are allocated to the application workload. However, the move away from SMPs to clusters has caused the file serving capability to become an external resource.

"If you were plowing a field, which would you rather use? Two strong oxen or 1024 chickens?"
- Seymour Cray, father of supercomputing

On "throughput-oriented data intensive" workloads, cluster administrators and users alike are discovering that performance not only fails to scale as more nodes are added, but the throughput actually starts to degrade. This phenomenon is perhaps best understood [at a high level] if you consider Seymour Cray's definition of a supercomputer: "a device that turns a compute-bound problem into an I/O-bound problem."

Clearly this is the case for commodity cluster technology today. As commodity processor technology accelerates with Moore's Law, the network bandwidth and file serving capabilities are falling farther and farther behind. How can we address the I/O corollary to Amdahl's law (the slowest component governs overall performance) in a way that does not add significantly to the cost structure of a cluster? Parallel file serving technology offers an answer.

Typically on clusters today, Workload Managers (WLMs) assign jobs to nodes based on application license availability and the cluster or grid's computational node characteristics (CPU availability, memory, local disk, etc.) Consequently, jobs are assigned to cluster nodes and each cluster node then attempts to acquire the requisite data file(s) from the file system (be it NFS or a parallel file system) through the network in a haphazard manner. This results in an I/O traffic jam that throttles the efficiency and scaling of throughput applications on the cluster.

This phenomenon of poor data provisioning results in the I/O time eventually swamping the compute time as node count increases. Poor data provisioning starves the cluster, resulting in a throughput performance curve that resembles a quadratic in the performance vs. node count space -- that is, run time improves as the number of nodes increases, but relatively less with each added node, up to some inflection point, then the time per job increases absolutely due to the continually increasing I/O burden becoming overwhelming.

Often these inefficiencies go unnoticed when one has not yet reached the inflection point, since the cluster CPU utilization, the network utilization and the file system all seem to be performing at acceptable levels. However, further analysis reveals that the cluster CPUs are busy waiting for data to arrive across the network from the file system and are NOT busy doing productive work.

Are you getting what you paid for?

When cluster administrators are asked whether their cluster is utilized efficiently, most would instantly and resoundingly say "YES." Often it's the users who have experienced performance degradation (or less improvement than expected) after a hardware upgrade who look at this issue more closely.

There are a number of methods available to measure the total efficiency of your cluster on specific applications. The easiest method is explained in the following two steps:

1. First, edit your run scripts and add "/bin/time" (or an equivalent command) where applications are launched. Then run the application on your entire cluster at once, using your normal method of file serving (e.g. NFS from a NAS system or parallel file system).

/bin/time blastall –p ...

2. Second, try pre-staging your files. Run the same script on a single node (or all nodes if you wish) but first transfer all input files to local disk (on each cluster node) and designate output files to be written locally. Collect the timings and calculate the efficiency ("user + system / real"). Compare the NFS (or other file serving mechanism) to the local disk resident results. You will likely be surprised to discover that you have a data serving bottleneck.

real: 160.1
user: 80.3
sys: 1.6

efficiency: 51 percent

Typically such tests take just a few minutes to set up and to analyze results. So with a minimum time investment on your part you can get an accurate picture of your cluster's processing efficiency on your favorite applications.

How parallel file serving technology can improve cluster efficiency

With a clear understanding of what limits cluster efficiency, let's look at ways to boost file serving capacity. Distributed file systems, parallel file systems, high bandwidth file serving devices, etc. exhibit better performance characteristics than standard NFS topologies, but do not provide a quantum leap in performance and are often prohibitively expensive to acquire. In the case of some parallel file systems, they are additionally very expensive when it comes time to expand storage capacity.

Parallel file serving technology with sophisticated error recovery and fault resilience techniques offer a method of replicating data sets ahead of applications being pushed to nodes. This is a novel and tantalizing approach to solving the data provisioning problem plaguing commodity clusters and edge grids today. However, replication as a parallel file serving technology is not a general-purpose solution and the characteristics of an application need to be looked at to determine whether this approach will significantly accelerate cluster throughput.

The ideal application profile is where the same, or substantially the same, large (300 MB to 50 GB) data set is being sent to each node of a cluster that utilizes 32 or more nodes. Examples of these types of ideal codes include Genome Searches (NCBI-BLAST), Medical Imaging, Weather Analysis, Rendering, etc.

However, many parallel applications work by splitting a problem via domain decomposition, such that each sub-task requires just a portion of the entire data set. So why replicate the whole data set on each node? Well there are many reasons.

First, there is always some overlap in the data set requirements between sub-tasks (boundary zones) requiring that part of the data set is sent many times over on the network. In such cases replicating the overlapped sections is more efficient.

Second, ordinarily each node runs multiple sub-tasks and over time each node will have utilized a significant proportion of the entire data set. In practice data sets are sent repeatedly over the network consuming bandwidth and aggravating network congestion. It makes sense then to send the data set just once to all nodes concurrently.

Third, when sub-tasks start to execute I/O, capacity is limited by the lesser of file serving and network capacity. In general file serving is less than 200 MB/s on a large cluster (500 MB/s with high-end specialized file servers). But when data is replicated to nodes the I/O capacity is linearly proportional to the number of nodes. So at 50 MB/s per node a cluster of 100 nodes can generate 5 GB/sec of I/O capacity, over an order of magnitude better than "top of the line" file servers.

Fourth, one has to take into account the file serving overhead which replication does not experience. The following is a real-world example of such overhead:

Recently CeBiTec, a leading bioinformatics research center located at Bielefeld University in Germany, tested the following scenario for parallel file serving performance. They provisioned 935 MB to each of 120 nodes over 1 Gbit Ethernet using a 250 MB/s file server with CacheFS and then, with replication technology. As you can see by the results below, replication from data residing on the file server was just as fast as CacheFS with a 100 percent hit rate on the local nodes and no dirty cache entries (the absolute best case for CacheFS). Compared to CacheFS with a dirty cache, or to regular V3 NFS, replication was over 20 times faster. This means that in the ideal case for file serving operation, where no actual data movement occurs (all data is perfectly cached on all nodes), it is still no better than straight replication from the original file server. This is what file serving overheads can do to degrade your cluster efficiency.

Method                            Time (mm:ss)

NFS v3                            14:50
NFS CacheFS (cache filled)      0:30 (estimated)
NFS CacheFS (cache dirty)       11:50
Replication                        0:35

Finally, few people believe replication can be made to scale on large clusters. The same research center also tested the scalability of replication. At 10 nodes replication to every node took 45 seconds and at 120 nodes it took just 35 seconds; better than linear scaling. While that result is somewhat unusual, nearly linear performance is typically seen, the point being that replicating to 100s of nodes costs about the same time as replicating to a few nodes.

What has to change to use replication?

Migration to a replication process takes very little time. There is no need to change the applications, Workload Manager, file server, networking or OS environment. Simply edit your job scripts and point to the local cache where appropriate when starting applications. Users can be up and running within the first day.

It is possible to address the scaling issue faced with data-intensive throughput workloads by employing parallel file serving technology, provided the technology supports sophisticated error recovery and fault resilience techniques and is designed for scalability to large numbers of nodes/clients. The technology should:

Solve synchronization, error recovery and back-up recovery issues of replication

Automatically pre-stage data, which means that while nodes are running a set of processes the data needed for the next set is pre-loaded in the background, thus completely eliminating file serving latencies and network bottlenecks

Automatically synchronize with Workload Managers to ensure that jobs only run when data is ready to be used at the nodes

Establish an efficient, asynchronous processing pipeline for both input and output data

Automatically clean up data sets that are no longer used

Automatically resynchronize nodes after a crash, automating complex and tedious management chores

With scalable parallel file serving, high performance technical computing on clusters becomes a reality for many more users.

"Make everything as simple as possible, but not simpler."
- Albert Einstein

-----

Benoit Marchand is the CEO and founder of eXludus and has been active in the field of high performance computing and distributed processing applications for over 20 years. He has held management positions at Sun Microsystems and SGI. He received an MBA from HEC in Montreal and a master's degree in computer science from the University of Waterloo.

Article Tools

Share Options

(Digg, Technorati, more)

Subscribe

Subscribe to HPCwire

Discussion

There are 0 discussion items posted.

Join the Discussion

You must be a registered user in order to comment on HPCwire stories.

Members enjoy:

	Access to Special Content, including Podcasts, Webcasts, and Whitepapers and more!
	Ability to take an active role in the discussions that are shaping the HPC technology discipline!
	Special offers available only to HPCwire members!

Become a Registered User Today!

Registered Users Log in Here to Comment

Email Address:	Password (case sensitive)

Remember me	Forgot Password?

RSS Feeds

Feeds by Topic

Feeds by Industry

Feeds by Content Type

Top Headlines

IBM Releases Energy Efficient Power7 System

Feb 09 | eWeek Europe | Company says new high-end servers will deliver "intelligent performance." Read more...

Inductive Coupling Packs Flash Drive in a Chip

Feb 09 | EE Times | Wireless technology promises energy-efficient chip-to-chip communication. Read more...

IBM, Microsoft Help Create Montana Supercomputer

Feb 08 | eWeek | A new kind of Rocky Mountain high. Read more...

AMD Aims for GPUs in Mainstream Servers Starting 2012

Feb 08 | Computerworld | Chip maker hopes to bring CPU-GPU processors to servers in two years. Read more...

Graphene Transistors That Work at Blistering Speeds

Feb 05 | Technology Review | IBM has created graphene transistors that leave silicon ones in the dust. Read more...

Read more headlines...

Featured Whitepapers

Virtualization for Aggregation And The vSMP Architecture™

Jan 12 | | In-depth look at vSMP Foundation server virtualization technology, technical implementation, use cases and capabilities. The technical whitepaper provides an architectural overview and details on the three vSMP Foundation products: vSMP Foundation for SMP, vSMP Foundation for Cluster and vSMP Foundation for Cloud.

Copper Cable Technologies for High Performance Computing

Jan 18 | | This white paper discusses Gore’s copper cable assemblies, and how they continue to exceed the standards for providing reliable, cost-effective solutions for high-performance computer applications.

Appro Assists LLNL with Cluster Designed for Extreme Scale Visualization

Jan 11 | | LLNL is home to some of the fastest computers in the world. In 2012, LLNL expects to have the Sequoia supercomputing cluster operational with a projected performance of over 20 PFLOP/s. These systems will focus on strengthening the foundations of predictive simulation through running large suites of complex simulations and then comparing model predictions with experimental data. To visualize this project’s large amount of data, LLNL requested an Appro Supercomputing Cluster specifically designed to support interactive data analysis.

View the White Paper Library

Multimedia

Webcast: Virtualized Data Center Roundtable

Join this online panel discussion for live Q&A with leading industry experts, analysts, and end-users to discuss the latest innovations, best practices, barriers to implementation, and measurable benefits of server virtualization with a particular focus on today's real world solutions.

Webcast: Watch SC09 Birds of a Feather Video: Scalable Fault-Tolerant HPC Supercomputers

Learn about scalable fault-tolerant architectures and examples of energy efficient and scalable supercomputing clusters using dual QDR InfiniBand to combine capacity computing with network failover capabilities with the help of programming languages such as MPI and a robust Linux cluster management package.

Webcast: High Performance Computing for a Smarter Planet

LIVE@SCO9: The IBM team discusses new innovations in hardware, software and services that help clients better understand their workloads and get insight from their R&D efforts. Technology demonstrations include the soon-to-be-released Power7 HPC processor, the DCS990 system with 2.4 petabytes of storage, the xCAT management tool, secure HPC cloud computing and more. Winners of two HPCwire Readers' and Editors’ Choice Awards! Take the IBM virtual tour at SC09 or more information go online to: http://www-03.ibm.com/systems/deepcomputing/sc09.html