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.

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.

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).

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.

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.

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

-----

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.