The San Diego Supercomputing Center Gordon Supercomputer was built in response to a call from the National Science Foundation (NSF) to deploy a “data intensive” computer. With this in mind, Gordon was designed for running data-intensive applications spanning domains such as genomics, graph problems, geophysics, and data mining. Scientific researches will include the analysis of individual genomes to tailor drugs to specific patients, the development of more accurate models to predict the impact of earthquakes on buildings and other structures, and simulations that offer greater insight into what’s happening to the planet’s climate.
CAPABILITIES OF THE GORDON SUPERCOMPUTER
The SDSC Gordon cluster is composed of over 1,000 compute nodes based on the Intel Xeon processor E5 family. The supercomputer also employs a number of unique capabilities to provide the data-intensive applications it was built to run. One of these features is very fast access to storage via 64 I/O nodes incorporating 300TB of high performance SSD flash-based memory connected over the InfiniBand fabric. This flash memory will help speed access to storage that is traditionally limited by the slower spinning disk-based storage. One benefit of this fast storage is to enable the manipulation of massive graphs that arise in many data-intensive fields, including bioinformatics, social networks and neuroscience. In these applications, large databases could be loaded into flash memory and queried with much lower latency than if they were resident on disk.
Each of these I/O nodes is capable of more than 560K IOPS, or 35M IOPS for the full system, making it what SDSC believes is the fastest supercomputer ever commissioned by the NSF in terms of I/O operations. For comparison purposes, the flash storage is large enough to store the entire 100,000 Netflix movie catalog (and still have room to spare), and is fast enough to deliver more than 200 Netflix movies in a single second.
Another concept unique to the Gordon cluster is the ‘Supernode’ architecture. Each Gordon supernode consists of 32 HPC compute nodes and is capable of 240 GFLOPS/node and 64 GBof RAM per node. Each supernode also incorporates 2 of the high speed I/O nodes detailed above. When tied together by virtual shared memory, each of the system’s 32 supernodes has the potential of 7.7 TFLOP of compute power and 10 TB of memory. An additional benefit of the cluster is the use of the supernodes are completely programmable, so the nodes can be allocated either as traditional HPC nodes, as supernodes, or as combinations of the two.
A 3D TORUS TOPOLOGY
SDSC chose to deploy a 3D Torus topology for the Gordon fabric. There are considerations to take into account when selecting between a 3D Torus and alternate topologies, but in some clusters there are key characteristics of a 3D Torus that make it a good choice. When comparing the 3D Torus to other topologies, the most often considered alternative is a fat-tree topology, which is the most commonly used topology for InfiniBand fabrics today. With a fat-tree topology, every node has equal access bandwidth to every other node in the cluster. Fat-tree is a great topology for running large scale applications where nodes do a lot of communication with each other, e.g., large MPI jobs. In contrast, a 3D Torus topology is best used for applications that use communications between localized compute nodes, as this locality is usually a requirement to achieve optimal performance with a torus. Given the data intensive applications that are targeted for Gordon, and the nature of these applications where in many cases localization constraints within the application are employed, the 3D Torus architecture made sense from a performance perspective.
There are additional advantages to be gained by using a 3D Torus topology that make it appealing for certain installations. In general the cabling of the cluster can be simpler, and also shorter cables can be utilized to build the cluster. This provides for a cost effective, power efficient and resilient design. Also, if future expansion is a requirement, the 3D Torus can be added to with very little re-cabling necessary. The ends of the torus are simply disconnected, servers are added, and then the torus is reconnected at the end points.
3D TORUS IMPLEMENTATION
To build their 3D Torus network, SDSC relied on InfiniBand hardware and software from Mellanox Technologies. The 3D Torus was built using 36-port switch nodes in a 4x4x4 configuration, for a total of 64 torus junctions. Each of these junctions connects to 16 compute nodes, and 2 IO nodes, with inter-node links using 3 switch ports in each of the +/- X, Y, and Z directions. Utilizing 40Gb/s QDR technology, this delivers over 12 GB/s of bandwidth in each direction. The cluster also employs a dual-rail technology, meaning two independent HCAs are populate in each server, and each HCA is connected to a separate 4x4x4 torus network. This provides the applications double the throughput from a server, or over 7 GB/s injection rate into the network.
Fig. 1 4x4x4 3D-Torus Logical Deployment Diagram
Mellanox used a unique algorithm called ‘Torus-2QOS’ to provide the packet routing configuration through the switching fabric. This algorithm, originally developed at Sandia National Laboratories, is based on Direct Ordered Routing (DOR) routing principles, but has the unique capability of being able to handle the loop wiring nature of a torus, and to also provide a level of Quality of Service (QOS) within the torus. QOS in important as it allows different traffic types, or service levels, their own dedicated network resources that won’t interfere with traffic from other service levels. This is especially useful in a cluster like Gordon, as the storage traffic from the IO nodes can run on their own service level from the compute traffic, giving each of these traffic types their own set of resources within the network where they won’t interfere with each other.
The Torus-2QOS algorithm that was deployed also has many advanced features, including its level of resiliency. The routing is setup in such a way that it can ‘self-heal’ and reroute around multiple cable failures as well as a complete switch failure. This rerouting is done automatically by the subnet management entity that is managing the fabric, and is done independently and without the knowledge of the applications running over the fabric.
While the details and interworking’s of the 3D Torus algorithm are beyond the scope of this article, from a simple conceptual view, separate ‘virtual fabric’ are employed in the switching network and used by the applications to avoid the credit loops discussed above. For example, a dateline is drawn in each plane of the torus, and if the packets cross this dateline they run over a different ‘virtual fabric’ from packets that do not cross the dateline. In this way, no loops are can be formed across the torus. Applications need to be aware of the correct ‘virtual fabrics’ to use when communicating to another server. Because InfiniBand uses a centralized management scheme, it is a rather straightforward process for the application to be given the ‘virtual fabric’ information from this centralized manager whenever setting up a connection to another server. Since most applications use this mechanism anyways, no changes to the application were necessary to be able to use the 3D Torus.
THE FUTURE OF 3D TORUS WITH INFINIBAND
The software that Mellanox deployed on the cluster is now industry standard and part of the open source community Open Fabric stack. This includes the subnet management routing algorithms, the management tools, and the application support to run over a 3D Torus topology. The San Diego Supercomputing Gordon cluster shows that it is feasible and practical to run a 3D Torus topology with InfiniBand. It also shows the power and flexibility of InfiniBand to be able to run different topologies depending on the performance goals, architecture and cost targets of the supercomputer.