There are many different ways that someone can actually buy and deploy a cluster.  Complete do-it-yourself experts buy all the parts themselves and do all of the work to assemble the solution.  These systems are called dark clusters because only the buyer really knows that the end-game is an HPC cluster.  There’s the turn-key cluster where the buyer purchases a fully working and assembled solution from a vendor.  Then there’s all kinds of ways in between with varying levels of interaction between cluster buyer and vendors selling solutions and parts.

With all these different paths, though, I’ve looked for common steps that are always performed during the purchase process.  After many hallway conversations and lots of coffee, I see there are four stages that always occur when buying an HPC cluster.  The variables in the different paths are the the division of labor, expertise, and cost that is divided between buyer and seller of the solution.  I define the four stages as follows:

Stage 1: Specifying the cluster.  This is the determination of what hardware and what software is required for the cluster.

Stage 2: Component integration.  Making sure the components spec’ed out in stage 1 actually work together is crucial.

Stage 3: Component manufacturing and software procurement.  The parts have to come from somewhere.

Stage 4: Physical deployment and testing. Where all the parts come together, the solution is built, and there’s some method of declaring the system ready for use.

Now, the model isn’t without flaws.  There are paths where the above stages are combined or may overlap, but I think the steps are all still performed.  With this in mind, I am exploring how different paths present barriers to wider adoption of HPC clusters as problem solving resources.  Some paths put too much expertise demand on the cluster buyer while other paths may put too much cost on the systems integrator.  A volume cluster market has to find paths that both lower the expertise required to buy a system and provide a cost-effective approach for vendors to deliver and sell those solutions.

Today, the field of computer simulation is on the threshold of a new era. Once reserved for national laboratories, large corporations and premier research universities, computer simulation is stepping out of the shadows and onto the main stage. Driving this migration is the need to reduce product development time and cost. Creating and testing a digital version of new products is proving to be less expensive and more complete than the costly physical prototyping method.

Product developers, from bicycles used in the Tour de France to power tools used to build your son that tree house, are employing ideas like digital prototyping, simulation based design or analysis driven design to create newer, more innovative products which impact the way we live.

Three forces are making it easier to employ simulations in the design process:
1) ISV’s are developing and deploying simple to use frameworks that make it easier to build, simulate and understand models

2) High Performance Computing is more affordable and accessible than ever before.

3) ISV’s and the technology industry are creating standards which are making it easier to deploy and maintain solutions

Independent Software Vendors like ANSYS, Altair, MSC Nastran and others are breaking the “expert” mold and making their products easier to use, extending the benefits of simulation based engineering to more users.

• Today, products like the ANSYS Workbench offer a straightforward easy to use framework that helps even the novice simulation engineer employ a rich suite of advanced engineering simulation technology. With its drag and drop framework, the ANSYS Workbench guides engineers through even some of the most complex multi-physics analyses. With bi-directional CAD connectivity, an automated project level update mechanism, pervasive parameter management and integrated optimization tools, the ANSYS Workbench delivers unprecedented productivity, enabling Simulation Driven Product Development.

• SimXpert, from MSC Software represents the next generation CAE application for modeling and analysis using FEA and multi-body dynamics (MBD). Integrated with MSC’s advanced multidiscipline (MD) solver technologies, SimXpert provides users an efficient easy to use “end-to-end” solution that takes engineers from CAD to analysis report in a single easy-to-use application. SimXpert provides native access to CAD data and easy-to use tools to automate their simulation jobs and get results fast. Its unified user environment also enables teams to share data, models, results and best practices across time zones, geographic boundaries, and CAE disciplines, so they can approach problems more consistently and get reliable results faster.

• HyperWorks, from Altair, enables efficient product design, evaluation, optimization, and validation, yielding insightful information and performance metrics that are necessary for sound and timely product decision making. With HyperWorks, users will be able to test and validate more design ideas, alternative materials and manufacturing methods in less time than ever before. It can also help users reduce the number of expensive physical models needed and speed up the design process. With HyperWorks, automation of routine and best-practice engineering tasks also permits a greater amount of virtual testing to be done efficiently.

High performance computing is now more broadly available than ever before.

Once reserved for glass rooms, supercomputers can now be found in your deskside workstation, office, department or division and, of course, in national laboratories and corporate data centers. HPC solutions are now more affordable, easier to use and accessible than ever before.

HPC, from the early days, was all about making the intractable problem tractable. Seymour Cray, the grandfather of HPC, was once asked to comment on the drivers of performance in HPC. He used one word as a response, and then continued to define it. The word he used was balance. Balance, of course, was comprised of several components which included processing power, memory capacity, memory bandwidth and system I/O. The reason for his focus on balance was its impact on delivered application performance. If you focus on only one of the resources (e.g. compute acceleration), you might find that delivered application performance is only a small fraction of the claimed performance improvement afforded by compute acceleration.

The new microarchitecture named Nehalem (the foundation of the Intel® Xeon® processor 3500 and 5500 series) rewrites the book on processor scalability, performance, and energy efficiency.

The Intel® Xeon® processor 5500 series is now a foundation component in most HPC solutions. Behind the performance of this new processor are several Intel technologies which create the balance necessary for the performance you need to solve large scale problems faster.

• Intel® Turbo Boost Technology. This technology (in combination with Intel® Intelligent Power Technology described below), delivers performance on demand, allowing processors to operate above the rated frequency to speed specific workloads and drop back down to reduce power consumption during low utilization periods.

• Intel® Hyper-Threading Technology. This well-known Intel innovation provides more performance for applications designed for parallel, multi-threaded execution by reducing computational latency and making optimal use of every cycle. Intel® Hyper-Threading Technology benefits from this latest Intel microarchitecture’s larger caches and massive memory bandwidth, delivering greater throughput and responsiveness for multi-threaded applications.

• Intel® QuickPath Technology. This new, scalable, shared memory architecture integrates a memory controller into each microprocessor and connects processors and other components with a new high-speed interconnect. It speeds traffic between processors and I/O controllers for bandwidth-intensive applications, delivering up to 3.5 times the bandwidth for technical computing.

• Intel® Intelligent Power Technology. This feature enables policy-based control that allows processors to operate at optimal frequency and power. Operating systems can make this determination automatically, or administrators can designate which applications require high-frequency processing and which should be executed at lower frequencies to conserve power.

Simplifying Clusters – Helping More Users Realize The Performance of HPC
The Intel® Cluster Ready mark represents compatibility, reliability, and quality to the buyer of the cluster and the components in that cluster. It is a program and technology package that is intended to make it easier to acquire and use clusters built with Intel components.

Intel® Cluster Ready is a program and technology that helps simplify the deployment, usage and management of clustered computer systems by providing a standardized and replicable way to build clusters and run “off-the-shelf” high-performance applications.

• ICR enables software developers to validate just one time across many hardware platforms, speeding development and time-to-market readiness.

• Intel Cluster Ready includes a software registration process for compatible HPC applications and a hardware certification process that utilizes the Intel® Cluster Checker. This tool checks the cluster hardware and software components to ensure they correctly interoperate.

• Intel Cluster Checker also includes fault isolation, helping to improve early detection of cluster problems that can decrease productivity and increase support costs.

Intel Cluster Ready Program Benefits and Advantages

Application Portability
• First and foremost: Intel Cluster Ready ISV applications have been tested to run on clusters certified as Intel Cluster Ready. You will no longer have to worry “if” your applications will run on a given cluster; instead, with a cluster certified as Intel Cluster Ready, you can focus on the features and performance you need to get your job done.

The result is:
• Reduced effort to configure, acquire, and deploy clusters that run the ISV applications you rely on.
• Increased productivity

Common Basis for Clusters
• The Intel Cluster Ready Specification is the key to Intel Cluster Ready; it eliminates sources of variability that do not impact performance, usability, or utility, but can spell disaster when left unspecified. Beyond documentation, the Intel Cluster Checker increases fidelity with direct measurements of conformance to specification and system performance. When support is needed, the Intel Cluster Checker speeds problem diagnosis, allowing you to return to productive work as quickly as possible.

You will benefit from:
• Improved operating experience, from initial power-on through continuing production operations
• Reduced support effort and costs
• Component Interoperability
• Components certified as Intel Cluster Ready which enable you to confidently select from a variety of hardware and software components. This is especially valuable as your computing requirements change, allowing you to modify existing capabilities and add new capabilities as needed.

The result is:
• Greater flexibility in cluster configurations
• Lower total cost of ownership
• Increased application performance

The Many Shapes Of High Performance Cluster Computers

The Digital Workbench
Once thought of as a design terminal, today’s workstation provides users with a digital workbench that is powered by two Intel Xeon 5500 series processors that can host a suite of software applications engineers employ to create and test their ideas. The pliers, hammer and nails found on a workbench in a garage or basement have now been replaced with digital tools that promise to accelerate innovations via a process known as digital prototyping. Its enablers include application tools such as detailed CAD, CAE and PIM. The digital workbench exceeds the computational power of the Cray C90 series, once revered as the fastest HPC in the previous decade. Together, the software advances of ISV’s and the performance of a digital workbench provide access to a powerful innovation tool you can use to bring your ideas forward faster than ever before.

Deskside Personal Clusters
Equipped with significantly more performance improvement from previous generation single core processors, the Xeon processor based deskside personal clusters such as the Cray CX1 supercomputer can deliver industry-leading performance across a broad range of applications and standard benchmarks, all in a compact, deskside system that plugs into a standard wall outlet. The personal cluster is designed for individuals and departmental workgroups as simple to configure, deploy, administer and use.

Personal clusters, like the Cray CX1, take the HPC cluster out of the data center and place it next to your desk. Your simulations just got faster; your productivity just hit a new high.

Cluster Based Supercomputing
Often called Beowulf clusters, cluster based supercomputing represents a collection of independent nodes that are assembled to attack your most computationally intense business problems. They are typically based on an array of Intel Xeon based processors connected via high speed digital fabrics ranging from GigE to infiniband based networks to provide amazing computational resources. They afford you an opportunity to scale the same architecture from small, medium and large-sized HPC deployments across a broad range of vertical markets like aerospace, automotive and consumer electronics.

Racked clusters such as the digital workbench and deskside personal cluster, offer you the greatest flexibility and best balance between computational load and memory bandwidth, and do not require as large a degree of code optimization as some other architectures that are available.

Which HPC Model Is Best For You
As we stated at the beginning of this article —– the field of computer simulation is on the threshold of a new era. The need to continually reduce product development time and cost is placing more pressure on industries in all verticals to adopt modern workflows that enable organizations to test a digital version of a new product before it is ever built.

If you are just starting to explore these new workflows or if you want to give your engineers an opportunity to move beyond design and allow them to digitally test their ideas against the defined design criteria, you may be better served with an array of digital workbenches rather than single socket workstations.

The digital workbench will allow you to move beyond CAD and allow you to not only design your next product, but also test it for form, fit, and function. The value of exploring multiple digital prototypes rather than just a single physical prototype will be very apparent.

If you have been doing simulation based design and you need to explore larger models, you may want to explore personal or departmental clusters like the CX1. These systems are designed for scalability and ease of use. They deliver remarkable performance in office friendly form factors, and are very capable at modeling complete car crashes in the same time frame used to modify your design.

The experts will tend towards large and extremely scalable Beowulf clusters. These systems provide access to immense resources that are capable of delivering the necessary processing power, memory capacity, memory bandwidth and system level i/o to solve the largest problems in as little time as possible. If you want to explore Intel technologies used in HPC solutions please visit our web site at http://www.intel.com/go/HPC

For more information about Intel Cluster Ready, go to www.intel.com/go/cluster

Authored by Wes Shimanek, Strategic Marketing Manager, Intel Corporation and Mike Haedrich, High Performance Computing Product Manager, Intel Corporation

This article by Intel Corporation was originally published 10-26-2009 on www.InventorConnections.com

First, always use the required and supplied “provisioning system” tools to update a cluster. It may be relatively easy to update all the nodes in a cluster using a couple RPMs and something like pdsh to script the installation of the update – but don’t be tempted.  This manual or brute-force method bypasses the software that manages the image on each server. Provisioning systems may reimage nodes after a crash or maybe a node is replaced or added to the cluster. If software updates are applied manually (outside of the provisioning system) then the reimaged node will be inconsistent with the rest of the system. An admin would need to remember all the manual changes and apply them again. It’s much better to let the provisioning software worry about that. That is one the reasons ICR required a provisioning system!

Once updates are applied, it’s a good idea to verify the cluster is working as it did before the update was installed and it remains compliant with the Intel® Cluster Ready architecture. Many if not most software updates will behave well, but verification helps ensure an update didn’t alter or remove a key system component that may lead to application failures. Intel® Cluster Checker provides an easy way to check the compliance after an update. By using the command-line –compliance option, the tool will verify the interface defined by the architecture still exists as before. It’s an easy way to check that the update hasn’t had any ill effect on the architecture interface used by ICR applications.

Finally, there may be needed updates to the Intel Cluster Checker configuration files to reflect the updated software. For example, if a newer version of the Intel C compiler is installed, the Intel Cluster Checker configuration file should be updated to utilize the newer version. Running the tool would then verify the new installation is functioning on all nodes. It’s also valuable to update the list of packages that are expected on each node. The packages test verifies the RPMs installed on each node matches a predetermined list. Using the –packages command-line option will create new package lists based on the current installation (use it after all updates are complete). Save the original list file and set the configuration file to use the updated list. For more information on using the tool, see the Intel Cluster Checker Users Guide.

Overview of Juropa

The name JuRoPA is itself an acronym which reflects the broader goals of the project of which this machine is just a part. JuRoPA stands for Jülich Research on Petaflop Architectures. The machine will be made available to over 200 research groups across Europe and will be used for data-intensive applications.

Figure 1: Juropa-JSC

JuRoPA’s architecture was developed by HPC experts from the Jülich Supercomputing Center. Partner companies Bull, Sun, Intel, Mellanox and ParTec were responsible for the realization of the machine which consists of 3288 compute nodes and a total computing power of 308 Teraflops peak.

The Juropa cluster is an aggregate of two smaller clusters, known individually as Juropa-JSC and HPC-FF. Both machines share a common interconnect fabric (QDR Infiniband) in addition to a common management network. ParastationV5, ParTec’s current release of it’s cluster operating system, enabled both clusters to be integrated to form a single heterogeneous cluster entity capable of solving the most challenging problems facing researchers today.

Figure 2: HPC-FF

Juropa’s Infiniband Network

The interconnect for the Juropacluster is common to both the HPC-FF and Juropa Machines. It is based on the latest Mellenox QDR Silicon but uses switches from two different vendors. Thetop level switching (level 1 and 2) is provided by 6 Sun (M9) 648 switches and 2 virtual M9 switches. The virtual M9 switches are topologically the same as the real M9 switches – but they are created using single instances of MTS3600 switches interconnected to replicate the internal connectivity of the actual M9’s.  These ‘virtual’ M9’s are shown in purple in figure 3.

Figure 3 - IB topology of JuRoPa

Infiniband Components

Figure 4: Sun 648 - M9

JuRoPa’s IB components are supplied by two different vendors, Mellanox and Sun. However, the basic building block of both switches is the same 36 port QDR InfiniScale® IV ASIC, the 4th generation of switch silicon from Mellanox.

The M9’s, of which there are six, provide most of the Level 1 and Level 2 switching for both the HPC-FF and Juropa-JSC machines. For the Juropa-JSC machine, the level zero switching is provided by the QNEM modules – or Quad-datarate Network Express Modules.  These QNEM modules integrated directly into the back of 6048 blade system. Connectivity to the HCA’s is achieved via back plane traces internal to the blade shelf. The HCA’s themselves are integrated into the serverboard using a 40 Gb/s InfiniBand ConnectX(R) mezzanine adapter card. This means there is no cabling to worry about between the HCA and the 1st level of switching.

Figure5: QNEM modules - 10 12x ports externally

It was recognised early on in the Juropa project that connectivity to the M9 switches (with 12X connectors) from the HPC-FF machine, which had regular QSFP (4x) HCA’s, required special cable considerations.  In order to connect the 1U servers of the HPC-FF machine to the M9, a special 12X -> 4X splitter cable was required, shown in Figure 6.  These are Sun prorietory  cables which the CPX connector no one end and 3 QSFP+ connectors on the other.

Figure 6: Sun splitter cable

Mellanox MTS 3600 switches for the Level zero switching for the HPC-FF cluster. These were connected to 4x QDR ConnectX HCA, housed in a standard PCI-E Gen2.0 8x slots on the 1U HPC-FF servers.  This connectivity was typically achieved with  QSFP copper cables of 2m length or less.

Why is the IB debugging strategy so important for Large Clusters

There are a myriad reasons why a cluster doesn’t perform to specification. These problems become difficult to manage on very large distributed memory machines.  For example,  there are a many combinations of node BIOS setting which can effect individual node performance. As MPI jobs progress at the speed of the slowest participant, it is essential that BIOS settings are both optimal and consistent across the whole cluster.  Tools such as Intel’s Cluster Checker are valuable  in spotting such inconsistencies and rectifying them. However, that is only part of the story. Node consistency checking and per-node benchmarking is important – but the network must also be considered. In particular, for commodity based clusters using an Infiniband Interconnect, the performance of the IB network itself can never be taken for granted.  A single link with high errors rates – resulting in either lost packets or significant data re-sends will impact performance across the whole cluster. These problems manifest themselves as either MPI job failures or general poor performance.

There were two basic objectives which were identified prior to planning the diagnostic activity for the Juropa cluster:

1. 1. Realize Per-Node parallel efficiency across the whole cluster of 3288 compute nodes
   2. Aid isolation and identification of faulty IB components – cables / ports/ HCA’s -  using location strings to identify the precise physical locations.

Goal 1 was quantified by stipulating a parallel efficiency in excess 90% (Nehalem Turbo Mode off). In particular, the parallel efficiency of the entire system should be about the same as that of a single compute node  provided there is nothing pathologically wrong with the Infiniband network, the cluster nodes are consistently imaged and configured and the MPI libraries have been suitably optimized.  This is the case of HPL benchmark runs with IB networks speeds in excess of DDR (5Gbps line rate). For QDR, as used in the Juropa machine, a line rate of 10Gbps is more than adequate.

For SDR IB network, the reduced bandwith would typically give a 2-4% downside in HPL benchmark performance. This is because LINPACK computations mostly communicate with process ranks which are immediate neighbors, and they do so with relatively large message sizes making the application somewhat bandwidth intensive.  As such, the HPL benchmark is not particularly latency sensitive.

The normal  single node parallel efficiency for the Nehalem based nodes used in the Juropa cluster is approx. 91%. This is with Turbo mode OFF. If the IB network is clean, BIOS settings are consistent and there are no hardware issues on individual nodes, then it should be possible to reproduce this efficiency across the entire machine.

Figure 7: Snippet of output of ibdiagnet - showing number of IB components

The second goal of the JuRoPa IB debugging strategy was to device a plan and construct a series of tools that enabled the integrator to quickly identify and replace faulty IB components by tying the error reports generated by the IB diagnostics tools with location strings of components on the machine floor. This was very important in a machine of this size, with 3881 individual IB components – as illustrated in Figure 7. The IB diags tools are very efficient at identifying where the errors in a fabric are and listing those errors with there associated GUID. A GUID is similar to a MAC address in the Ethernet world. Each IB component has a separate GUID. However, in a fabric containing this many components, locating a faulty component when you only have a GUID to go on is a daunting challenge. Integrators could simply record the base GUID of each switch component in a spread sheet – and search that spreadsheet for the corresponding machine room location for the faulty component. However, this a time consuming and inefficient manner to proceed. What is needed is a to link the switch location with the ibdiags tools so the location strings for components becomes part of the diagnostic output. This is done using a IB topology file.

Juropa Floor Plan – understanding the topology files

The IB topology file can be used to specifically reference the locations with reference to there connectivity to other components. Figure 8 below details the floor plan of the Juropa cluster.  As you can see – there are 2 distinct systems. The first (in green) is the HPC FF and the second (in orange) is the JSC cluster.

Constructing Infiniband topology Files

A topology file has 2 core uses:

1. Topology files can be used to specify the intended connectivity of a IB network. The topology file can then be used in conjunction with the ibtopodiff utility (part of the ibdiags package in the OFED stack) to determine if there are any discrepancies between the intended topology and the physical one.  This helps the network engineer identify potential cabling errors that might cause traffic congestion in the physical network.
2. Topology files can be used to append location strings to specific specific connection sources and destinations. In figure 9 below, we can see that a Mellanox MTS3600 switch located at location C9 (rack location on floor plan)  position U (vertical location in rack) has port 19 (for example) connected to a Sun M9 switch #1  located at rack location A7. The connecting port is on line card 7 and is labeled B8/P1 on the silk screen.

Figure 9: Extract from topology file

Topology files such as the one shown in Figure 9 above are typically derived from the netlist developed by the integrator. MTS3600 and SDCIB648 are subsystem components which themselves have there own connectivity files (IBNL) files. These files are typically included in the OFED stack.

Bringing it all together

Once you have your topology file and the IBNL files are in the correct directory of the OFED stack – we are ready to start the process of debugging the fabric. There a two basic tools that where used as detailed below:

1. ibdiagnet:
   ibdiagnet is a tool is a tools that uses IB’s in-band diagnostics functionality. It is run from any node connected to the fabric provided that node has the OFED stack installed and both the IBNL files and the topology files are accessible.  ibdiagnet scans the fabric using directed route packets and extracts all the available information regarding its connectivity and devices.

2. mpilinktest:
   mpilinktest is an mpi application created by the  Jülich Supercomputing Center, the host site for the JuRoPa cluster. mpilinktest is a parallel ping-pong test between all connections of a machine. Output of this program is a full communication matrix which shows the bandwidth between each processor pair and a report including the minimum bandwidth. The linktest runs
   for n processors in n steps where in each step n/2 pairs of processors
   will perform the MPI pingpong test (3 iterations, 128 kB
   messages). The selection of the pairs is random but after running all
   steps all possible pairs are covered.

ibdiagnet is used to capture the symbol, receive link, link width (links not running at 4x) and topology errors. However, ibdiagnet is not good at generating the  high volumes of traffic typically seen when the machine is in production.  mpilinktest is the tool used to generated the traffic while the data is simulaniously collected using  ibdiagnet.

Typical diagnostic output

Figure 10 below details the typical output given by ibdiagnet when a approprite ibnl and topology files are used.

Figure 10: ibdiagnet output given when using ibnl and topology files.

Taking the 2nd error, as an example. The location string NEM8_A6_D/IS4B/U1/P22 is interpreted as follows:

• NEM8 is the name given to this QNEM unit.
• A6 is the location of the rack containing this module – it is given as Isle A, location 6. See figure 8.
• D is the vertical location of the module within  the rack – running A thru D, with A in the bottom. This unit is at the top of the rack.
• IS4B is the instance of the ASIC with that unit. Each QNEM has two ASIC, IS4A and IS4B.
• U1 should be ignored. P22 is the port instance which has the error on that particular ASIC. Each ASIC has 36 ports.

For the above we note that although we can isolate the location of the QNEM module to a particular location in a particular rack, we cannot yet determine which particular physical port on the QNEM has the issue. To achieve this, we need to understand more  about the internal layout of the QNEM module. Figure 11 details the internal connectivity of the Sun QNEM module.

Figure 11: QNEM internal connectivity.

Figure 11 suggests that IS4B Port 20 connects to the blade in Slot 8. As such, this particular link does not represent a cable – rather an internal backplane link to a Sun Blade server.  This is the end of the diagnostic process as we have now identified a pair of component one of which is faulty. IB errors are reported at the receiver, as such, for this particular error we know that the problem is either the blade connection to the backplane or the backplane connectivity to the QNEM.  Indeed, it could  be the backplane itself. Either way, the service engineer task is now to swap each component individually with a known good component until the problem is resolved.

Summary – Evaluation of Goals

The first goals outlined earlier was to achieve in excess of 90% parallel efficiency across the whole cluster for HPL type benchmarks. Additionally, another goal was to be being able to quickly identify where the problems are in this JuRoPa IB network.

Today, errors in the JuRoPa cluster are quickly locatable. The preparation detailed herein was invaluable in bringing JuRoPa to production. Its true to say that the identification of errors, whilst not an unskilled job, has been significantly simplified by the methods detained herein.

During HPL (LinPack) benchmarking tests undertaken in early June ’09  the JuRoPa machine achieved an impressive 274.8 Trillion floating point operations/second recorded over a sustained 11 hour period. This was achieved using 3221 compute nodes each running 8 Nahalem cores. This LinPack performance constitutes 91.6% of peak− making JuRoPA the global leader in parallel efficiency for commodity supercomputer clusters.

High Performance Computing (HPC) pushes the limits of computing performance, enabling people in science, research, and business to solve computationally intensive problems, such as those in chemistry or biology, quantum physics, petroleum exploration, crash test simulation, CG rendering, and financial risk analysis. HPC cluster systems have almost single-handedly propelled the HPC market’s skyrocketing growth in recent years and drove HPC revenue past $11 billion in 2007. IDC expects that HPC will remain one of the bright spots in the IT space over the next few years, despite of the troubled global economy.
For HPC, clusters are firmly entrenched as the dominant species of technical server revenue. Within the HPC cluster universe, 1U rack-mounted server clusters continue to play an active role because of their large global installed base and the advantage of being highly available as a commodity product. In addition, rack-mounted clusters allow users to mix and match servers from different vendors within and across racks with no vendor lock-in. However, the sales momentum in recent months has shifted decidedly toward blade-based clusters, especially as blade technology has matured.

Click here to download “Red Hat HPC Solution”

SGI, a leader in high-performance computing, is a founding platform partner of the Intel® Cluster Ready program. SGI recognizes the outstanding value that the Intel Cluster Ready program offers customers and has certified both the SGI Altix* ICE integrated blade platform and the SGI Altix XE advanced cluster platform as Intel Cluster Ready. Intel Cluster Ready recipes give customers yet another great reason to deploy SGI Altix ICE and SGI Altix XE clusters. Because Intel Cluster Ready makes it easier for ISVs to run their optimized software on the SGI platform, customers can rapidly and costeffectively implement industry-specific solutions that meet the demanding requirements of high-performance computing.

Click here to download “SGI and Intel® Cluster Ready Program Brief”

Click here to download “Scalability of Transient CFD on Large-Scale Linux Clusters”

Appro and Intel® Cluster Ready — Extreme Performance, Extreme Scalability
Find out how Appro is delivering a complete High Performance Computing solution for the customer, integrating both hardware and software at a reasonable price while lowering the total cost of ownership.