Since 1986 - Covering the Fastest Computers in the World and the People Who Run Them

Language Flags
October 5, 2007

ASC Labs Create Unified Strategy to Add HPC Capacity

by Michael Feldman

On Tuesday, Appro announced the win of a $26.1 million government contract to deliver eight Linux clusters to three DOE National Nuclear Security Administration (NNSA) weapons laboratories. Starting next month, Lawrence Livermore National Laboratory, Los Alamos National Laboratory and Sandia National Laboratories will begin deploying the new Appro Xtreme-X high performance clusters. The quad-core Opteron-based systems will provide an aggregate performance of 438 teraflops and will be used to provide capacity computing for the NNSA’s Advanced Simulation and Computing (ASC) and Stockpile Stewardship Program.

In 1995, the ASC was conceived to support the NNSA’s mission of maintaining the country’s nuclear arsenal without the benefit of underground nuclear testing. By shifting almost entirely to a compute-based program, the NNSA began an enormous effort to modernize their simulation codes in order to provide a virtual testbed for weapons analysis and certification. Prior to 1995, each of the three laboratories — Lawrence Livermore, Sandia, and Los Alamos — purchased their own computer systems based on site-specific schedules and budgets. With the inception of the ASC program, the three labs began to coordinate their efforts more closely.

The Appro contract is significant because, for the first time, the ASC labs have teamed up to purchase and deploy a number of systems with a single architecture and a standard software stack. According to Mark Seager, ASC lead for Lawrence Livermore, “This is an historic procurement. It’s the first time the Tri-Lab community has aggregated its requirements and bought a single set of high performance computing resources for all three sites.”

This unified purchasing strategy reverses the natural tendency for the labs to buy a diverse range of systems using separate procurements. The reason for the change of heart: money. Under a very limited budget, the program needed to increase their capacity computing systems by an order of magnitude. The labs came to the conclusion it would more efficient to band together, and instead of doing six separate procurements over the next two years — one per lab per year — they would do a single procurement for the entire two-year period.

To achieve the level of cost reduction the ASC program was going after, the procurement was designed around a single hardware design point, called a “Scalable Unit” (SU). Based on the scalable unit module, multiple clusters of varying sizes can be built. By making a volume purchase of scalable units, the ASC program is looking to achieve an economy of scale similar to that of purchasing a single large system.

Each SU consists of 144 four-socket, quad-core Opteron nodes, hooked together with DDR InfiniBand. Each node comes with 32 GB of memory. The initial procurement consists of 21 SUs spread out over eight clusters: three for Lawrence Livermore (8 SU, 2 SU, and 1 SU systems), two for Los Alamos (two 2 SU systems), and three for Sandia (three 2 SU systems, one of which will be housed at Lawrence Livermore). The ASC labs have the option to purchase an additional 10 SUs, valued at $15.8 million.

The basis of this strategy is that the SU can be used as a highly replicated unit to build clusters of different cluster sizes, depending upon programmatic requirements. Systems ranging in size from 1 SU to 16 SU are fair game, although the largest one planned is the 8 SU, 162 teraflop cluster at Lawrence Livermore. If constructed, a 16 SU system would approach Blue Gene/L in raw computational performance.

But the idea is not to compete with capability machines. The clusters are slated for the day-to-day computing work of the ASC program, such as algorithm development. This type of work typically does not require supercomputing scalability and often uses 2D (rather than 3D) calculations or has some of the physics code turned off. Once the algorithms are developed, they’re scaled up, integrated into full simulations and run on one of the ASC supercomputers — Blue Gene/L and ASC Purple at Lawrence Livermore, Red Storm at Sandia, or ASC Q at Los Alamos. These applications may run for months at a time on these big machines, making those systems unavailable for algorithm development.

As it turns out, the capacity requirements of the ASC program are now on the same order of magnitude as their capability requirements, FLOP-wise. A lot of this can be attributed to the success of the ASC program in delivering simulation codes that can scale to 100 teraflops or more, and thus fully utilize the existing capability machines. Some physical weapons testing is still done, but it’s very expensive. As a result, economics is pushing the government to do more virtual weapons testing, which is causing an acute demand for compute resources. Since the capability machines are in such demand for fully-scaled simulation runs, the more compute cycles that can be placed on the less expensive capacity systems, the better.

In addition to the SU hardware reference platform, the procurement also defined a common software stack, which consists of Red Hat Enterprise Linux (RHEL5U1), the OpenFabrics Enterprise Distribution InfiniBand stack, MVAPICH and Open-MPI, and the MOAB/SLURM resource manager. A common set of Fortran, C and C++ development tools are also specified. The site-specific software components include the parallel file system, as well as the RAS and system monitoring software.

Cost reduction comes from a number of areas. Because of the size of the procurement, the vendors are able to reduce their costs and pass them along to the buyer. The economies of scale apply to both component and system vendors. And since all the systems are based on the same architecture, integrating and deploying them should be simplified. In fact, last year Appro installed three clusters of the same architecture at Lawrence Livermore under the Peloton procurement. Experience with those installations is expected to reduce individual cluster deployments to just six weeks or less.

Once deployed, operational costs should be reduced as well, since support expertise can be amortized throughout the Tri-Lab community. The common hardware and software environment streamlines the support structure in dealing with bugs, spare parts and system maintenance. Seager said the application developers will be especially happy to have the same hardware at all three sites.

Overall, the ASC bean counters estimate they’re reducing their total cost of ownership by 30 to 50 percent relative to their normal practices. Since Linux clusters are already 50 percent less expensive than their high-end capability machines like Purple and Blue Gene, the reduced TCO is very compelling.

This is all good news for Appro (as well as contract co-awardees Mellanox and Voltaire), who beat out five other vendors to win the Tri-Lab procurement. According to Seager, the other bidders were spread out over tier 1, tier 2 and tier 3 system vendors. He noted that the tier 1 vendors tended to be well-qualified, but too expensive. On the other hand, the tier 3 vendors presented too much risk; apparently some just delivered PowerPoint slides for their bid. Seager said technical innovation was not an important criteria in this case; they were looking for ease of operation and rapid deployment.

By contrast, the ASC capability systems are all about innovation. Seager said for these best of breed machines, they are quite willing to accept greater levels of risk that this level of technology brings. And while they might be tempted to employ a unified purchasing model for their capability systems, it turns out not to be very practical.

“We can’t afford to purchase multiple of these machines in any one year or even successively over two years,” explained Seager. “This is a significantly different model than what we are doing for capacity systems with the [Tri-Lab procurement]. Unfortunately, most of the basic insights that we leveraged for lower TCO on the highly replicated, multiple cluster procurement don’t hold for capability systems.”