Im Westen Deutschlands befindet sich eine der derzeit aktuell beeindruckendsten Konzentrationen von purer Rechenkraft: Das Forschungszentrum Jülich beherbergt drei der momentan schnellsten Supercomputer an einem Platz.
Europas Spitze
Vorzeigeobjekt des Jülich Supercomputer Centers (JSC) ist dabei fraglos "Jugene", rangiert das System doch zur Zeit auf Platz 3 der Top500-Liste der schnellsten Rechner weltweit - und nimmt so auch die Top-Position in Europa ein. Mit einer Peak-Performance von rund 1 PetaFLOPS erreicht man im LINPACK-Benchmark eine Geschwindigkeit, die in etwa mit 25.000 aktuellen PCs vergleichbar ist. Hinter Jugene steht eine Plattform, die die Welt der Supercomputer in den letzten Jahren dominiert hat: IBMs Blue Gene/P.
Aufbau
In der konkreten Ausformung am JSC besteht das System aus 294.912 CPU-Kernen, dabei kommen auf eine CPU jeweils vier Kerne. Wie von IBM gewohnt, kommen hier PowerPC-Prozessoren zum Einsatz, konkret der PowerPC 450, der mit 850 MHz getaktet ist. So ein umfangreiches System benötigt freilich einiges an Hauptspeicher, um seine volle Kraft entfalten zu können, 2 GB pro Node sind es hier, was in Summe ein RAM von beeindruckenden 144 TByte ergibt.
Und die braucht es auch, wie Prof Dr. Dr. Thomas Lippert, Direktor des JSC, gegenüber dem WebStandard herausstreicht: Ist doch hier keinerlei vom Privatrechner bekannter Swap-Speicher vorgesehen, dies würde Jugene durch die massiven Storage-Zugriffe deutlich in die Knie zwingen. So müssen die NutzerInnen also schon selbst genau aufpassen, dass sie mit ihrem Speicher haushalten, wollen sie die erzielten Daten nicht verlieren.
Vorsicht
Eine Vorsicht, die auf solchen Systemen aber überhaupt gilt: Ein Notstromsystem gibt es beim JSC nicht, fällt der Strom sind die gerade bearbeiteten Daten unwiederbringlich weg. Ein Ausnahme bilden dabei lediglich die Storage-Systeme, wie Dr. Norbert Eicker erklärt, schließlich sollen diese in so einem Fall noch geordnet heruntergefahren werden, um Beschädigungen zu verhindern. Entsprechend werden die NutzerInnen dazu angehalten regelmäßig selbsttätig "Checkouts" durchzuführen, um so die relevanten Daten auf die Speichermedien zu bannen. Auch eine andere Maßnahme beschränkt die Gefährlichkeit eines Verlustes: Rechenzeit am Jugene wird in maximalen Chargen von 12-24 Stunden abgegeben, danach kommen wieder andere BenutzerInnen dran.
Doch neben Jugene stehen am JSC noch zwei weitere Supercomputer, an denen man beinahe noch ein Stück mehr hängt: Ist doch etwa JuRoPA direkt aus der eigenen Cluster-Forschung entstanden, das System verdeutlicht den zunehmenden Trend zur Verwendung von Commodity-Hardware, die zu Clustern zusammengeschlossen wird. Rund drei Viertel aller Rechner in der Top500-Liste seien derzeit bereits als Cluster aufgebaut, illustriert Eicker, der selbst als Architekt von JuRoPA am JSC firmiert, die Situation.
Chips
Als CPUs setzt man hier auf Intel-Chips der aktuellen Generation, konkret kommen hier Xeon X5570 (Quad-Core Nehalem-EP, 2,93 GHz) zum Einsatz, auf 2208-Servern sind jeweils zwei der Prozessoren verbaut. Um die Nehalem-Architektur zum Einsatz bringen zu können, hat man beim JSC sogar einige Verzögerungen von Seiten Intels in Kauf genommen, dies hat einen simplen Grund: Die neue Chipgeneration bringt erhebliche Fortschritte bei der Speicherbandbreite, in früheren Zeiten ein Schwachpunkt der Intel-Chips. Mit 32 GBit/s ist die Nehalem-Generation nun aber bestens aufgestellt, etwas dass auch eine recht hohe Effizienz der Systeme bei LINPACK ergibt.
Ein weiterer Bereich, in dem es derzeit zu einer gewissen Konsolidierung kommt, ist jener der Netzwerkanbindung. Während hier in der Vergangenheit ein Wildwuchs verschiedenster proprietärer Systeme zu beobachten war, hat sich das Ganze im Top500-Bereich mittlerweile weitgehend auf zwei Lösungen ausgedünnt. Der Großteil setzt hier bereits auf "gewöhnliches" Gigabit-Ethernet, ein Ansatz von dem Eicker aber nur wenig hält.
Entscheidungen
Dies reiche vielleicht aus um im relativ simpel zu optimierenden LINPACK-Benchmark weit oben zu landen, im Real-Einsatz ließen sich dann aber nicht annähernd die potentiellen Werte erzielen. Im Sinne eines ausgewogenen Systems kommt bei JuRoPA also QDR-Inifiniband zum Einsatz. Dessen Bandbreite liegt bei satten 32 GBit/s, der wirklich relevante Wert sei allerdings ohnehin ein anderer, wie Eicker im Gespräch herausstreicht: Die Latenzzeit von rund 2 Mikro-Sekunden (im Real-Einsatz, versprochen sind eigentlich 1 Mikro-Sekunden) ermöglicht einen äußerst flotten Zugriff
Reigen
Im Aufbau praktisch ident ist das dritte der großen Supercomputersysteme am JSC: Der HPC-FF besteht allerdings "nur" aus 1080 Cluster-Knoten, das System ist speziell für die Fusions-Forschung gedacht. Bei Bedarf lassen sich JuRoPA und HPC-FF zusammenschalten, gemeinsam ergibt sich dann eine Rechenleistung von rund 300 TFLOPS.
Alle Systeme teilen sich das Storage-System LUSTRE von Sun, sechs Petabyte an Platz stehen hier zur Verfügung. Zur Kühlung setzt man mittlerweile weitgehend auf Wasserkühlung, auch wenn dies zum Teil noch mit einer klassischen Lüftung kombiniert ist.
Entwicklung
Auch wenn dies natürlich ein äußerst hoher Betrag ist, muss doch herausgestrichen werden, dass aktuelle Supercomputersysteme wesentlich energieeffizienter sind als noch vor einigen Jahren: Während die Leistung massiv angestiegen ist, ist der Stromverbrauch in den letzten Jahren annähernd gleich geblieben.
Cluster
Softwareseitig bestimmen zwei Komponenten den Aufbau von JuRoPA und HPC-FF: Da wäre einmal die Cluster-Software ParaStation, die zwar dem Hersteller ParTec gehört, deren weitere Fortentwicklung aber zwischenzeitlich von einem Konsortium gesteuert wird. Die ParaStation ist seit 2004 offiziell Open Source, aktuell ist die Version 5 der Software.
Als Betriebssystem kommt - wie mittlerweile bei beinahe allen Supercomputern - Linux zum Einsatz, konkret SUSE Linux Enterprise 11. Die Distribution hat im Bereich High Performance Computing (HPC) eine lange Tradition, schon vor der Übernahme durch Novell hatte sich SUSE im Supercomputer-Umfeld engagiert. Als entscheidende Vorteile für SLE verweist Ecker auf den Support und die gute Zusammenarbeit mit den Novell-EntwicklerInnen.
OS-Jitter
Wie das funktionieren kann, demonstrierte Novell in einer eigenen Präsentation an einem Fallbeispiel: Eines der Probleme, mit denen man derzeit im HPC-Bereich zu kämpfen hat, ist das sogenannte OS-Jitter, das zum Teil deutliche Performance-Einbussen mit sich bringt. Die Ursache ist eigentlich eine recht kleine: Auf einem Betriebssystem laufen typischerweise diverse Daemons und Interrupts, die regelmäßig Mikro-Unterbrechung des Rechner-Ablaufs verursachen. Was bei einem einzelnen Rechner nicht weiter ins Gewicht fällt, hat bei der massiven Parallelisierung von Cluster-Systemen verheerende Auswirkungen. Da hier alle Nodes auf den Aussetzer eines einzelnen Systems warten müssen, akkumulieren sich diese Verzögerungen zu einer relevanten Größe.
Ein Problem, das man von mehreren Seiten angehen will, einerseits in dem das Betriebssystem auf das absolut Notwendige reduziert wird, etwa in dem praktisch alle Daemons deaktiviert werden. Zugleich soll aber auch ein Realtime Kernel Einzug halten, dessen Möglichkeiten Dr. Matthias Nagorni, Produkt Manager bei Novell, verdeutlichte. Hier können zeitkritische Aufträge genau getimet werden, eine Zuverlässigkeit, die auch für einige andere Bereiche durchaus relevant sei. So sei der SLERT-Kernel ursprünglich auf Wunsch von Kunden aus dem Finanz-Business entstanden, bei denen exaktes Timing unter anderem für Algorithmen-basiertes Trading oder Real-Time-Risk-Management benötigt wird. Aber auch für andere Bereiche, wie die Übertragung von Audio- oder Videodaten sei Real-Time hilfreich.
Latenz
Typischerweise gebe es bei wachsender Last auch stärkere Latenzprobleme, ein Problem, das sich bei einem Real-Time-Kernel nur wesentlich schwächer zeigt, wie Nagorni betont. Für den realen Einsatz sei es dann etwa möglich einen Kern für zeitkritische Aufgaben zu reservieren, während die anderen wie üblich weiterlaufen. Maßnahmen mit denen der OS-Jitter erheblich reduziert werden könne, wie der Novell-Manager dann auch noch an einem konkreten Beispiel demonstrierte. Dabei konnte er durch einige Optimierungen den OS-Jitter von 50ms auf 20 Mikro-Sekunden reduzieren.
Im Rahmen einer Führung durch die eigenen Räumlichkeiten ließen die Verantwortlichen des JSC dann nicht nur einen etwas näheren Blick auf die aktuellen Systeme von Jugene bis zu JuRoPA zu, auch eine kleine Vorschau in eine mögliche Zukunft wurde gewährt. Mit QPACE bastelt man derzeit an einem System, das auf der Cell-CPU basiert, die ähnlich auch in der Playstation 3 zum Einsatz kommt. In gerade einmal zwei Racks hat man damit ein System verbaut, das jetzt schon auf einen LINPACK-Wert von 50 TFLOPS kommt. Freilich handelt es sich dabei noch um einen Prototypen, ein größeres System auf dieser Basis wird es wohl erst in frühesten 5 Jahren - so sich denn der Ansatz überhaupt als alltagstauglich erweise.
Vergabe
Die Nutzungszeiten auf den Supercomputern werden übrigens deutschlandweit von einem Gremium vergeben, im Vordergrund steht dabei die zivile Forschung. So rechnen die Systeme zu unterschiedlichsten Themen, von der der Optimierung von Blutpumpen bis zur Frage wie das Leben angefangen haben könnte. Kommerziellen Kunden gegenüber sei man zwar nicht prinzipiell abgeneigt, doch aus unterschiedlichsten Gründen hätten diese nur wenig Interesse. Allen voran stehen dabei Sicherheitsüberlegungen bzw. die Angst davor, dass durch ein nicht-eigenes System Firmengeheimnisse nach außen gelangen könnten. (Andreas Proschofsky [@suka_hiroaki auf Twitter], derStandard.at, 19.07.2009)