September 22, 2006
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:
-----
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.
Jun 18, 2013 |
The world's largest supercomputers, like Tianhe-2, are great at traditional, compute-intensive HPC workloads, such as simulating atomic decay or modeling tornados. But data-intensive applications--such as mining big data sets for connections--is a different sort of workload, and runs best on a different sort of computer.
Read more...
Jun 18, 2013 |
Researchers are finding innovative uses for Gordon, the 285 teraflop supercomputer housed at the San Diego Supercomputer Center (SDSC) that has a unique Flash-based storage system. Since going online, researchers have put the incredibly fast I/O to use on a wide variety of workloads, ranging from chemistry to political science.
Read more...
Jun 17, 2013 |
The advent of low-power mobile processors and cloud delivery models is changing the economics of computing. But just as an economy car is good at different things than a full size truck, an HPC workload still has certain computing demands that neither the fastest smartphone nor the most elastic cloud cluster can fulfill.
Read more...
Jun 14, 2013 |
For all the progress we've made in IT over the last 50 years, there's one area of life that has steadfastly eluded the grasp of computers: understanding human language. Now, researchers at the Texas Advanced Computing Center (TACC) are utilizing a Hadoop cluster on its Longhorn supercomputer to move the state of the art of language processing a little bit further.
Read more...
Jun 13, 2013 |
Titan, the Cray XK7 at the Oak Ridge National Lab that debuted last fall as the fastest supercomputer in the world with 17.59 petaflops of sustained computing power, will rely on its previous LINPACK test for the upcoming edition of the Top 500 list.
Read more...
05/10/2013 | Cleversafe, Cray, DDN, NetApp, & Panasas | From Wall Street to Hollywood, drug discovery to homeland security, companies and organizations of all sizes and stripes are coming face to face with the challenges – and opportunities – afforded by Big Data. Before anyone can utilize these extraordinary data repositories, however, they must first harness and manage their data stores, and do so utilizing technologies that underscore affordability, security, and scalability.
04/15/2013 | Bull | “50% of HPC users say their largest jobs scale to 120 cores or less.” How about yours? Are your codes ready to take advantage of today’s and tomorrow’s ultra-parallel HPC systems? Download this White Paper by Analysts Intersect360 Research to see what Bull and Intel’s Center for Excellence in Parallel Programming can do for your codes.
Join HPCwire Editor Nicole Hemsoth and Dr. David Bader from Georgia Tech as they take center stage on opening night at Atlanta's first Big Data Kick Off Week, filmed in front of a live audience. Nicole and David look at the evolution of HPC, today's big data challenges, discuss real world solutions, and reveal their predictions. Exactly what does the future holds for HPC?
Join our webinar to learn how IT managers can migrate to a more resilient, flexible and scalable solution that grows with the data center. Mellanox VMS is future-proof, efficient and brings significant CAPEX and OPEX savings. The VMS is available today.