Traditionell arbeitet der Münchner Hersteller von Strahltriebwerken für Flugzeuge mit großen Unix-Rechnern von SGI, um die Jet-Aggregate zu entwickeln. Ende der 90er Jahre entschloss man sich, die Berechnungsverfahren auf dynamische Prozesse und probabilistische Verfahren auch für 3D-Modelle auszudehnen. Und zwar möglichst günstig, denn die IT-Budgets befinden sich seit Jahren auf konstantem Niveau. Linux kam ins Gespräch, um die Unix-Mainframes von den Massenanwendungen zu entlasten.
Machbarkeit im Kleinen getestet
Im Jahr 2000 entstand aus einer Kooperation mit der TU München im Rahmen einer Diplomarbeit ein Cluster aus vier einfachen PCs, auf dem Linux lief und auf das zwei Anwendungen für "Computational Fluid Dynamics" (CFD) zur Simulierung des aerodynamischen und thermischen Verhaltens von Triebwerken portiert wurden. Im Prinzip funktionierte das System, was den Ausschlag für die Entscheidung gab, ein Linux-basierendes PC-Cluster aufzubauen.
Mit den Planungen dafür begann eine Arbeitsgruppe um Norbert Diehl, Teamleiter Information Systems Engineering, und Projektleiter Axel Philipp im Frühjahr 2001. Im folgenden Herbst kam die Hardware: 64 Dell-Rack-Server des Typs "Poweredge 1550" mit je zwei 1,13 Gigahertz schnellen Pentium-III-CPUs und insgesamt 144 GB SD-RAM. Untereinander wurden sie per Myrinet (2 Gbit/s) vernetzt und mit Fast Ethernet (100 Mbit/s) an das Unternehmensnetz angebunden.
Als Betriebssystem gelangte Linux Enterprise Server 7 von Suse zum Einsatz, allerdings in einer bis in den Kernel hinein stark reduzierten Version mit speziellen Bibliotheken und Patches für die Myrinet-Netzkomponenten. Der ansonsten nicht geänderte Linux-Quellcode würde auf ein paar Disketten passen. Eine "Load Sharing Facility" (LSF) sorgt dafür, dass die Rechenlast auf den Knoten im Cluster ausbalanciert bleibt.
Das Ganze wurde in die bei der MTU vorhandene DV-Umgebung integriert, was von vornherein eine Prämisse war. "Die besondere technische Herausforderung bestand in der nahtlosen Integration des Linux-Clusters in die bestehende heterogene Server-Infrastruktur", blickt Projektleiter Philipp zurück. Denn das Cluster hat nur temporären Plattenplatz, alle permanenten Daten liegen auf anderen File-Servern. Dabei erwies es sich als hinderlich, dass die Linux-PCs 32-Bit-Systeme sind, während die SGI-Umgebung im 64-Bit-Modus arbeitet. Das schafft im Netz-File-System Probleme, die sich schließlich dadurch lösten, dass SGI das eigene File-System XFS überarbeitete.
Gute Kooperation im Projekt
Dieses Entgegenkommen hebt Teamleiter Diehl lobend hervor, schließlich hatte SGI der MTU diesmal keine Hardware verkaufen können. Auch mit Suse und T-Systems, das auf der Grundlage eines Outsourcing-Vertrags die Administration der gesamten DV einschließlich des Clusters trägt, sei die Zusammenarbeit besser gewesen, als man erwarten durfte.
Der Personalaufwand für das Projekt war mit insgesamt vier Personen von der MTU, Suse und T-Systems sehr gering. Die Feinabstimmung der portierten CFD-Anwendung dauerte kaum eine Woche. Aufgrund seiner Affinität zu SGIs Unix-Variante Irix waren Arbeiten an Linux und die Anpassung der Applikationen kein Problem, zumal Diehl das quelloffene Betriebssystem seit der Version 0.91 kennt.
Der Betalauf startete Anfang 2002, und im Mai vergangenen Jahres ging das Linux-Cluster endgültig in Betrieb. Seither läuft es ohne Unterbrechung. "Wir haben noch keinen Crash gehabt, weder bei Linux noch bei den Anwendungen", lobt Diehl, "und das bei nahezu 100 Prozent Last." Nur einige defekte Myrinet-Karten mussten ausgetauscht werden, was in einem Cluster kein Problem macht. Die Performance liegt je nach Anwendung um zehn bis 20 Prozent höher als erwartet. Diehl: "Da sind die Entwicklungsingenieure als End-User natürlich zufrieden." Die von T-Systems übernommene Administration ist nicht aufwändiger als für andere Unix-Systeme.
Unschlagbares Preis-Leistungs-Verhältnis
Ein besonders wichtiges Argument für das Linux-Cluster ist seine Wirtschaftlichkeit. "Wir haben uns nicht für die billigste, sondern für die Lösung mit dem weitaus besten Preis-Leistungs-Verhältnis entschieden", erläutert Diehl. "Im Vergleich mit Supercomputer-Lösungen auf Unix-Basis sind die Gesamtkosten für die gleiche Rechenleistung bei unserem Linux-Cluster um den Faktor 2,5 bis drei günstiger."
Als Konsequenz wurde bald beschlossen, das Cluster auf 300 CPUs auszubauen, allerdings gleich mit schnelleren Xeon-Prozessoren. "Rechenleistung können wir gar nicht genug haben", kommentiert Diehl. Die Erweiterung wurde innerhalb von zwei Monaten abgeschlossen und steht den Anwendern inzwischen produktiv zur Verfügung. Schrittweise werden weitere Anwendungen an Linux angepasst, allerdings nicht alle. Diehl: "Wir portieren Anwendungen mit hohen CPU-Belastungen bei ansonsten moderaten Anforderungen."
Nicht für alles sind Cluster gut
Der Teamleiter spricht damit eine Eigenart von Linux-Clustern an. "Die sind im Engineering-Bereich empfehlenswert für Anwendungen, die hohe CPU-Leistungen verlangen, aber darüber hinaus keine exorbitanten Anforderungen wie extrem großen Hauptspeicherbedarf oder sehr üppige I/O-Bandbreite stellen." Immerhin könne man mit Linux-Clustern, so Diehl, "einen sehr hohen Prozentsatz der Anwendungen abdecken". Allerdings solle man die Programme jeweils testen. "Manche Applikationen laufen auf Linux nicht ohne weiteres sehr performant."
Wichtig sei es, gibt Diehl möglichen Nachahmern den Rat, "genau auf die Integration in die vorhandene Infrastruktur zu achten". Es sei zu empfehlen, statt Billigangeboten "sehr stabile Hardware zu kaufen". Und wer dann noch die Administration in gute Hände gebe, könne mit Linux-Clustern noch mehr sparen, so Diehl.
Steckbrief
Ziel: Kostengünstiger Ausbau der verfügbaren Rechenleistung durch Nutzung eines Intel-basierenden Clusters.
Unternehmen: Triebwerkbau
Herausforderung: Integration in vorhandene IT-Umgebung (SGI, Unix).
Zeitrahmen: Frühjahr 2001 bis Ende 2002.
Stand: Cluster läuft seit Mai 2002 (erste Ausbaustufe) produktiv.
Ergebnis: Erhebliche Kosteneinsparungen gegenüber vergleichbarer Supercomputing-Lösung.
Basis: 300 Intel-basierende Rack-Server, "stripped-down" Suse Linux, zwei Anwendungen für Computational Fluid Dynamics.
Realisierung: Inhouse, Suse, T-Systems, SGI.
Nächster Schritt: Linux-Portierung weiterer Anwendungen.