"Schon als Gymnasiast interessierte ich mich für Hochleistungsrechner"

Olivier Byrde hat 1992 an der Ecole polytechnique fédérale de Lausanne (EPFL) in Angewandter Mathematik und numerischer Analysis diplomiert. Sein Doktorat erlangte er ebenfalls an der EPFL 1997 in Computational Fluid Mechanics im Bereich der Mischung von Flüssigkeiten. Dabei beschäftigte er sich mit massiv parallelem Rechnen. 1998 erhielt er eine Anstellung bei Cray Research, die damals eine Abteilung von Silicon Graphics war. Dort war es seine Aufgabe, Kunden wie die ETH und Meteoschweiz zu betreuen und ihre Applikationen zu optimieren. 2002 bekam er an der ETH selbst eine Anstellung als Applications Analyst und Cluster Administrator. 2007 wurde er Leiter der neu geschaffenen High Performance Computing Group an der ETH.

Herr Byrde, Sie beschäftigen sich seit 20 Jahren mit Supercomputing – ist das nicht ein Traumjob für jeden Informatiker?

Ja, das ist ein Traumjob. Ich interessierte mich eigentlich schon als Gymnasiast für Hochleistungsrechner. Während meines Doktorats an der EPFL konnte ich dann das erste Mal mit einer Cray arbeiten. Anschliessend hatte ich das Riesenglück, bei der Firma Cray einen Job zu bekommen. Sie war damals der Inbegriff des Supercomputerherstellers und sozusagen der Traumarbeitgeber für alle, die sich dafür interessierten. Klar, es gab noch einige Zweitligisten, aber Cray war das Zauberwort in der Branche. Als Mitarbeiter dieser Firma kam ich schliesslich auch an die ETH. Ich hatte die Aufgabe, den Leuten dort zu helfen, effizient mit dem Supercomputer zu arbeiten. Diese Maschinen kosten ja einige Millionen, und wenn man sie nicht effizient nutzt, verschwendet man Geld.

Und seit wann beschäftigen Sie sich mit Hochleistungs-Clustern?

Mit Cluster Computing begann ich 2004. Zu jener Zeit hat die ETH noch alle paar Jahre einen neuen Cluster angeschafft. Weil die neuen Cluster aber nicht als Ersatz für die alten, sondern zusätzlich angeschafft wurden, brauchte es laufend neue Informatiker, um sie zu betreiben. Auch ich war für den Nutzersupport eines dieser Cluster eingestellt worden und lernte so on-the-job, wie man eine solche Maschine betreibt.

Wurden die Cluster damals fertig gekauft oder selbst gebaut?

Sie wurden nicht gerade ab Stange, aber doch mehr oder weniger konfektioniert gekauft. Jedenfalls wurden es immer mehr und im Grossen und Ganzen war es üblich, dass jeder Cluster von einer Fachperson betreut wurde. Das wurde mit der Zeit einfach zu teuer. Ausserdem führte es dazu, dass jeder Verantwortliche seinen Cluster nach seinen eigenen Vorstellungen betrieb, was am Ende zu unterschiedlichen Systemen führte. Für Nutzer, die auf verschiedenen Systemen arbeiteten, war das ein Albtraum. In dieser Situation kamen meine Kollegen und ich zum Schluss, die Cluster zu vereinheitlichen. Wie Sie sich vorstellen können, gestaltet sich ein solches Vorhaben an einer Hochschule aber ziemlich schwierig. Glücklicherweise hatte dann aber der Leiter der Informatikdienste ein Einsehen und stellte sich hinter die Idee. So gründete er 2007 die High Performance Computing Group und übertrug mir die Leitung.

Und dann ging es plötzlich?

Das erste Jahr investierte ich in Gespräche mit meinen Kollegen. Zuerst hatten wir noch die Idee, die bestehenden Cluster so weit zu vereinheitlichen, dass wir sie alle auf dieselbe Weise betreiben konnten. Hierfür suchten wir ein gemeinsames Betriebssystem, einheitliche Management-Tools und Policys. Aber im Lauf dieser Arbeiten realisierten wir, dass wir bereits 90 Prozent der Vorarbeiten geleistet hatten, die es braucht, um einen einzigen zentralen Cluster aufzubauen. Da beschlossen wir, die restlichen 10 Prozent auch noch zu machen. Daraus entstand dann das Konzept für Brutus. Um es zu testen, bauten wir 2007 einen neuen Cluster – Brutus 1, wenn Sie so wollen. Damit konnten wir zeigen, dass es sich in der Praxis bewährt. Danach integrierten wir alle vorhandenen Cluster zu einem System.

Was ist eigentlich die technische Leistung der ETH beim Aufbau von Brutus?

Unser Beitrag ist sozusagen der Klebstoff, der all die unterschiedlichen Komponenten verbindet. Wir wollten grundsätzlich keinen Code selbst schreiben, da bereits gute Open-Source-Software verfügbar war. Das Zusammenfügen der vorhandenen Tools an sich war nicht besonders kompliziert. Wirklich anspruchsvoll war in unserem Fall, dass wir sehr heterogene Hardware zusammenbringen mussten. Es gab Rechenknoten mit zwei Kernen, solche mit 16 Kernen oder 48 Kernen. Wir hatten unterschiedliche Speicher, Netzwerke und so weiter. Zeitweise liefen 12 unterschiedliche Servertypen im Cluster. Die Kunst war es, alle diese Unterschiede zum Verschwinden zu bringen. Meine Rolle dabei war es, darauf zu achten, dass die Nutzer ein möglichst einfaches System erhalten und sich nicht darum zu kümmern brauchen, was darunter alles läuft. Ich glaube, hier liegt am Ende auch der Erfolg unseres Ansatzes. Das ist ein wichtiger Grund dafür, dass die Nutzergruppe rasch wachsen konnte.

Auf welchem Betriebssystem läuft der Cluster?

Als Basis nutzen wir eine spezielle Linux-Distribution, die sich CentOS nennt und wiederum auf der freien Version des Enterprise Linux von Red Hat aufbaut.

Mussten sie während des massiven Ausbaus von Brutus in den letzten Jahren etwas am Grundkonzept ändern?

Nein. Wir haben von Anfang an dahin gearbeitet, dass sich Brutus problemlos skalieren lässt. Das ist fast wie Lego: Wir können neue Bausteine ganz einfach hinzufügen. Deshalb verstehen wir Brutus eigentlich auch nicht als Cluster. Für uns ist er eine Plattform für den Bau von Clustern. Innerhalb dieser Plattform können Sie fast alles ändern, sogar während das System läuft.

Das System ist hot plugable?

Nicht hot plugable im üblichen Sinn. Wir können jederzeit einen Teil des Systems herunterfahren und dort Dinge verändern, ohne dass der Nutzer etwas davon merkt. Wenn aber das ganze Netzwerk oder der zentralen Storage ausgetauscht werden soll, dann müssen wir den Cluster ganz abschalten.

Hat Brutus Grenzen beispielsweise bezüglich der maximalen Anzahl Knoten?

Es gibt Grenzen, doch die werden durch die limitierte Energieversorgung oder Kühlleistung in unserem Rechenzentrum vorgegeben. Ein weiteres Skalierungsproblem bereitet uns das einzige kommerzielle Stück Software, das wir verwenden. Dabei handelt es sich um ein Ressource-Management-System, das die verfügbaren Ressourcen und die anstehenden Aufträge überwacht und aufeinander abstimmt. Hierfür gäbe es zwar Open-Source-Lösungen, aber die sind nicht so stabil und effizient, wie wir uns das wüschen. Deshalb entschieden wir vor vielen Jahren, die Softwareplattform LSF zu lizenzieren. Sie wird pro Kern lizenziert. Deshalb bekamen wir nach jedem grösseren Ausbau einen Schock, als wir die Rechnung erhielten. Wir konnten die Konditionen aber neu verhandeln und mit dem Anbieter eine tragbare Lösung finden.

Wie ergänzen sich Ihr Cluster und die Supercomputer im Hochleistungsrechenzentrum Manno, auf die die ETH ja auch zugreifen kann?

Das sind zwei völlig verschiedene Organisationen. Das CSCS ist vom Bund finanziert und steht grundsätzlich allen Hochschulen zur Verfügung. Wenn Sie dort rechnen wollen, müssen Sie zuhanden des Betriebskomitees einen Projektantrag einreichen. Wird er für interessant befunden, bekommen Sie Rechnerzeit, wenn nicht, müssen Sie eine andere Lösung suchen. Dafür ist die Nutzung dort gratis. Bei Brutus gibt es keine vorherige Prüfung. Wir stellen einfach die Ressourcen bereit und lassen die Mitglieder selbst entscheiden, was sie rechnen wollen.

Wie finanzieren Sie den Cluster?

Wenn ein Professor bei Brutus mitmachen will, dann investieren wir das Geld, das er zur Verfügung stellt, beispielsweise in neuen Rechenknoten. Das heisst, die Professoren suchen zuerst Geld für ihre Computing-Vorhaben und investieren es dann in Ressourcen bei Brutus.

Was hat Brutus bisher etwa gekostet?

Seit 2007 haben die Brutus-«Shareholders» etwa 10 Millionen Franken investiert, das heisst etwa 2 Millionen pro Jahr.

Ich habe gehört, dass mittlerweile 50 Professoren an Ihrem Cluster beteiligt sein sollen – wie bringt man die unter einen Hut?

Die Lösung besteht darin, auf die Bedürfnisse der einzelnen Professoren einzugehen, anstatt sie als Kollektiv zu sehen. Nur so ist es möglich, herauszufinden, wie viele Ressourcen wirklich benötigt werden und dementsprechend die beste Lösung zu finden. Dies schafft nicht zuletzt auch gegenseitiges Vertrauen, was extrem wichtig ist. Es ist eigentlich keine schwierige Aufgabe, sie nimmt aber viel Elan und Zeit in Anspruch. Die zu investieren lohnt sich aber: Wir brauchen keine Werbung für den Brutus-Cluster zu machen, weil er durch Mundpropaganda weiterempfohlen wird. So konnten wir das System über die letzten fünf Jahre um einen Faktor 50 vergrössern.

Sie haben also einen grossen Topf, in den alle einzahlen, ohne auf die technischen Entscheidungen Einfluss nehmen zu können?

Bei den technischen Entscheidungen können die Professoren tatsächlich nicht mitreden – das ist wichtig. Ich rede mit ihnen eigentlich nur darüber, was sie an Rechnerleistung brauchen. Oft tue ich das mit zehn Professoren gleichzeitig. Die Frage ist dann, ob wir eine Lösung finden, die die Bedürfnisse dieser Beteiligten mehr oder weniger abdeckt. Wenn sie etwas wirklich Exotisches wollen, dann muss ich passen. Wenn es ins Konzept passt, definiert mein Technikspezialist, welche Hardware wir hierfür benötigen, dann schreiben wir den Auftrag aus, kaufen und installieren. Ein Ökonomieprofessor, der nahezu von Anfang an dabei ist, bezeichnete unser Konzept im Scherz einmal als wohlwollende Diktatur. Das trifft die Sache recht gut (lacht).

Sie sagen, ihr Cluster sei im Schnitt zu etwa 90 Prozent ausgelastet. Wie funktioniert das, ohne dass sich jemand benachteiligt vorkommt?

Wir haben im Normalfall genug Jobs in der Warteschlange, um den gesamten Cluster fünfmal zu füllen. Das gibt dem System den Spielraum, Benutzerprioritäten zu berücksichtigen und die vorhandenen Ressourcen gerecht zu verteilen. Gleichzeitig schafft das Voraussetzungen für eine möglichst hohe Auslastung.

Und was tun Sie, wenn die Wartezeiten zu lang werden?

Momentan haben wir rund 18 000 Kerne. Davon sind innerhalb einer Minute rund hundert disponibel. Wenn Sie also 100 Kerne benötigen, haben Sie eine gute Chance, dass Ihr Job innerhalb weniger Minuten startet. Wenn das System stark ausgelastet ist oder Sie deutlich mehr Kerne benötigen, müssen Sie ein, zwei Stunden oder vielleicht einen Tag warten. Das wiederum erzeugt Motivation für weitere Investitionen unter den Beteiligten.

Sie bauen Ihren Cluster mit marktüblichen Blade-Servern – wo liegen die Grenzen solcher Hardware im Vergleich zu Supercomputern?

Technisch gesehen besteht ein klassischer Supercomputer auch heute noch aus spezifischer Hardware, die ihn für Rechenaufgaben mit sehr hohen Ansprüchen prädestiniert. Ein typischer Unterschied zu Clustern sind die proprietären Netzwerke, die seine Rechenknoten untereinander verbinden. Diese Verbindungen sind sehr breitbandig. Deshalb laufen riesige Jobs auf Supercomputern schneller als auf Clustern. Das interne Netzwerk macht aber auch einen grossen Teil des Preises eines Supercomputers aus. Aus Sicht des Nutzers heisst das: Wenn seine Applikation nicht auf sehr schnelle Verbindungen zwischen den Knoten angewiesen ist, wäre ein Supercomputer reine Geldverschwendung.

Was ist der Vorteil eines Clusters, der nach und nach aus verschiedenen Hardwaregenerationen aufgebaut wird?

Wichtig ist vor allem, dass wir den Nutzern Kontinuität bieten können. Sie merken nicht, wenn wir etwas am Rechner verändern – ausser vielleicht, dass sie danach weniger lange auf Ihren Job warten müssen. Dann kommt die Psychologie hinzu: Wenn Sie mehrere Maschinen unterschiedlichen Alters parallel betreiben, dann wollen alle immer nur auf dem neuesten arbeiten. Das können wir mit unserem Konzept umgehen. Weil das System selbst entscheidet, welche Jobs auf welchen Ressourcen laufen, lassen sich auch die ältesten Knoten gut nutzen. Unsere ältesten laufen schon seit etwa fünf Jahren.

Handeln Sie sich mit so alten Rechnern nicht eine schlechte Energieeffizienz ein?

Ja, das ist eine der Kehrseiten der Medaille. Alte Hardware ist natürlich weniger effizient. Typischerweise brauchen unsere neusten HP-Knoten um etwa den Faktor 17 weniger Strom pro Rechenoperation als ihre Vorgänger.

Gibt es eine Altersguillotine für Rechenknoten?

Nein, es gibt keine harte Regel. Weil der Platz im Rechenzentrum aber begrenzt ist, werden alte Systeme dann ausgetauscht, wenn wir zusätzliche Rechenleistung benötigen. Dasselbe gilt hinsichtlich des Energieverbrauchs.

Haben Sie schon weitere Ausbaupläne?

Ich verhandle gerade mit mindestens fünf Professuren, die sich neu beteiligen wollen. Zusätzlich wollen etwa zehn Professuren ihre bestehenden Knoten erneuern. Jetzt kommt es darauf an, ob wir eine kritische Menge von neuen Knoten zusammenbekommen, damit wir bald eine Ausschreibung machen können.

STICHWORTE

Das kann ich jederzeit empfehlen:
Eine möglichst offene Kommunikation mit den Kunden, Benutzern und Mitarbeitern.

Darüber habe ich zuletzt gelacht:
Der typische Lebensstil von Informatikern wie er in der britischen Fernsehserie «The IT Crowd» gezeigt wird.

Darüber habe ich mich zuletzt geärgert:
Ich bin eine zurückhaltende und ruhige Person. Sich über etwas zu ärgern, bringt einen nicht weiter und macht es nur schwerer, konstruktive Lösungen zu finden.

Heute in zehn Jahren:
Heute in zehn Jahren, also am 29. August 2022, ist ein Montag, da bin ich mir ziemlich sicher. Alles andere können sie mich dann nochmals fragen.

ZUR FIRMA

High Performance Computing Group der ETH Zürich

Die HPC-Gruppe (High Performance Computing) evaluiert, beschafft, installiert und betreibt Hochleistungssysteme und bietet ihren Benutzerinnen und Benutzern umfangreiche Unterstützung in allen Bereichen. Die Gruppe zählt 6 Mitarbeiter.

Seit 2007 baut und betreibt sie den Cluster Brutus. Er besteht zurzeit aus 983 Rechenknoten mit 18 400 Prozessorkernen. An dieser Rechnerleistung partizipieren derzeit mehr als 50 Professuren. Mit 190 Teraflops (190 × 1012 Fliesskomma-Operationen pro Sekunde) wäre er in der Top-500-Liste rund um den 120. Rang zu finden. Weil die ETH aber nicht an dem Wettbewerb teilnimmt, ist er dort nicht zu finden. Typischerweise verarbeitet Brutus rund 2 Millionen wissenschaftliche Simulationen pro Monat. Er konsumiert 450 kW.