Decommissioned First Linux Cluster

aus dem Jahresbericht 1999:

Angestoßen durch Beschwerden von Kunden aus dem Jahre 1997, die ihre langlaufenden, nicht vektorisierenden Berechnungen auf der IBM SP2 des LRZ (im seriellen Modus, also nicht parallel) durch häufige Fehler oder Wartungsmaßnahmen an diesem komplexen Rechner vorzeitig zunichte gemacht sahen, kamen Überlegungen in Gang, hier Abhilfe zu schaffen. Sie mündeten in die Bereitstellung zunächst eines, dann zweier Intel-PCs unter Linux und der Chemie- Software „Gaussian“. Zuvor waren Vergleichsmessungen mit IBMs Power-Prozessoren sehr ermutigend für Intel verlaufen. Bevor schließlich ein vorläufiges Cluster mit 8 Linux-PCs in Betrieb gehen konnte, wurden

  • Spezielle Netz-Hardware und –Software ausgewählt („Myrinet“)

  • Spezielle Cluster-SW ausgewählt und installiert (MPI, PVM)

  • Boot-ROMs für die 6 Client-Nodes erstellt, die einen Boot via NFS von den Cluster Servern erlaubt.

Es läuft mit 2 Servern und 6 Clients und bearbeitet vorerst vor allem Chemie-Anwendungen. Eine Ausweitung dieser  Compute-Plattform ist geplant, hängt allerdings von der Genehmigung eines entsprechenden HBFG-Antrages ab. „Schrankfertige“ Ansätze für Linux-Cluster wiewurden bisher aus Preisgründen verworfen.

aus dem Jahresbericht 2000:

Erste Ausbaustufe und Zielsetzungen

Wie bereits im Abschnitt über den Parallelrechner SP2 erwähnt, genügen die dort verfügbaren Hauptspeicherressourcen seit längerem nicht mehr den Anforderungen der Benutzer. Aus diesem Grunde wurde (nachdem vorher umfangreicheErweiterungen an der Stromversorgung im PEP durchgeführt wurden, die auch den Betrieb der neuen Archivserver, des Visualisierungsrechners und des ESS ermöglichten) bereits im Jahr 1999 8 Pentium Doppelprozessoren (mit mindestens 512 MB Hauptspeicher) beschafft. Zunächst gingen einige dieser Knoten für serielle Batch-Jobs mit hohen Hauptspeicher-, vor allem aber auch langen Laufzeitanforderungen in den Benutzerbetrieb. Nach internen Tests von Software und Myrinet- Vernetzung wurde im März 2000 der parallele Benutzerbetrieb aufgenommen.

Ziel ist zum einen, die Programme derjenigen Benutzer vom SP2 weg zu migrieren, die sie dort entwickelt haben und laufen lassen; zum anderen, eine Musterinstallation für diejenigen Institute anbieten zu können, die selbst ein solches Cluster beschaffen wollen. Neben der Installation der Hardware ist auch die zentrale Pflege der Benutzer-Dokumentation sowie die Verfügbarmachung von Lizenz-Software durch das LRZ zur Nutzung im Münchner Hochschulnetz ein wesentlicher Beitrag zur Erreichung dieser Ziele.

Es ist zu bemerken, dass das Linux-Cluster - gerade auch um die Erfahrungen zu sammeln, die eine Benutzerunterstützung erst ermöglichen – nicht nur am LRZ selbst entworfen und aufgebaut wurde, sondern auch eigengewartet wird. Dabei spielt natürlich die Gewährleistung der Komponenten eine wichtige Rolle, es verbleibt jedoch ein nicht zu vernachlässigender Arbeitsanteil in der Erstanalyse von Fehlern, in der Abstimmung verschiedener Komponenten (z. B. der PCs mit der Software und den Komponenten des internen Cluster-Netzes) und im Mehraufwand, der durch die Einzelbeschaffungen entsteht. Trotz des erheblichen Personaleinsatzes erspart das LRZ dabei weit mehr als die Personalkosten der eingesetzten Mitarbeiter ausmachen, erhält deren Motivation, weil sie an vorderster Entwicklungsfront mitarbeiten können und gewinnt Erfahrung, die den Hochschulen zur Verfügung steht.

Beim Aufbau des Clusters bereiteten zunächst der Betrieb eines RAID-Systems mit gespiegelten Dateisystemen und die Nutzung von NFS die häufigsten Probleme. Viel detektivischen Scharfsinn erforderte das Aufdecken von falschen Programmergebnissen durch fehlerhaft arbeitende CPUs. Negative Erfahrungen ergaben auch Versuche, etwa Hardware-Prefetch durch den Linux-Kernel unterstützen zu lassen. Nach einigen längeren Betriebsausfällen in den ersten Monaten konnte im Lauf der zweiten Jahreshälfte jedoch ein hoch stabiler Betrieb bei hoher Auslastung durch Benutzerjobs herbei geführt werden. Um hardwarebedingte Ausfälle zeitlich kurz zu halten mussten neben Ersatzplatten (erwartet) auch Lüfter für die CPUs (unerwartet) bevorratet werden. 5.2.1.5.2 Hardware-

Konfiguration der 2. Stufe

Wie schon im Jahresbericht 1999 erwähnt wurde schon Mitte 1999 ein HBFG-Antrag auf ein Linux-Cluster gestellt, um die Benutzeranforderung angesichts der bevorstehenden Abschaltung des SP2 auch leistungsmäßig auffangen zu können. Aus formalen Gründen verzögerte sich dieser Antrag, musste 2000 weitgehend umgeschrieben werden und wurde erst Ende Herbst 2000 endgültig genehmigt. Dies verzögerte viele Pläne, machte zusätzlich viel Arbeit und machte es notwendig, dass aus eingesparten SP2-Wartungskosten schon im vorab ein kleineres Linux-Cluster aufgebaut wurde. Nach der Genehmigung des HBFG-Antrags konnte der weitere Ausbau des Clusters wie ursprünglich geplant vorangetrieben werden. Bis Ende 2000 stand die folgende Gesamtkonfiguration zur Verfügung:

  • Fileserver (RAID) lxsrv0 für Bootkonfiguration und paralleles File-System (NFS, 70 GB). Pentium III/500 Doppelprozessor, 512 MB Hauptspeicher

  • Interaktivmaschine lxsrv1, Pentium II/450 Doppelprozessor, 1 GB Hauptspeicher

  • Erster paralleler Pool lxsrv2-lxsrv7, Pentium III/500 Doppelprozessoren, 512 MB Hauptspeicher (mit Ausnahme von lxsrv3, der 1 GB Hauptspeicher hat) (als Ersatz der parallelen Batch-Knoten am SP2)

  • Serieller Pool: lxsrv8-lxsrv10, Pentium III/800 Doppelprozessoren mit 1 mal 1 GB und 2 mal 4 GB GB Hauptspeicher sowie lxsrv13-lxsrv18, Pentium IV/1500 Einfach-Prozessoren mit je 1 GB Hauptspeicher (als Ersatz der seriellen Batch-Knoten am SP2)

  • SMP-Maschinen für große shared-memory Programme: lxsrv11 und lxsrv12 sind 4-fach SMP’s mit Pentium III-Xeon/700 („Cascades“) Prozessoren, je 2 MB Cache je Prozessor sowie 4 GB Hauptspeicher je Knoten (als Ersatz der Memoryserver-Knoten am SP2)

  • weiter paralleler Pool lxsrv19-lxsrv26: Pentium III/800 Doppelprozessoren, je 1 GB Hauptspeicher) (als Ersatz der parallelen Batch-Knoten am SP2)

Systemsoftware und Betriebskonzept

Das Bootkonzept für die ursprüngliche erste Ausbaustufe des Linux-Clusters ist ein „diskless node“- Konzept, d. h. die System-Partitionen jedes Nodes liegen auf dem NFS-Server lxsrv0, der demzufolge gebootet sein muss, bevor man die Clients aufsetzen kann. Über ein Boot-PROM in den Netzkarten wird von jeder Maschine ein Kernel-Image ebenfalls von lxsrv0 eingelesen. Bei der gegenwärtigen Größe des Clusters gibt es noch keine Skalierungsprobleme, der Hauptflaschenhals ist gegenwärtig hauptsächlich die lange Bootdauer des Servers lxsrv0. Hier ist auf Verbesserungen in der Systemsoftware (evtl. zukünftiger Einsatz eines journaled Filesystems wie reiserfs) zu hoffen. Da bei der Erweiterung des Clusters damit zu rechnen war, dass das 100 MBit-Ethernet den Anforderungen beim Booten des Clusters nicht gewachsen ist, sind alle Ende 2000 neu beschafften Maschinen mit einer lokalen Betriebssystem- Installation versehen worden, können also unabhängig vom Netz gebootet werden.

Für den globalen Zugriff auf große benutzerseitig generierte Dateien ist das Andrew-File-System (AFS) sowohl wegen der dort erforderlichen Kontingentierung als auch wegen der Performance ungeeignet; daher steht am Cluster als paralleles Dateisystem eine NFS-gemountete, 70 GB große Partition zur Verfügung. Im Vergleich mit AFS erhält man zwar eine deutlich bessere Performance, jedoch treten insbesondere bei der Verwendung durch parallele Programmen Skalierungsprobleme auf. Daher ist vorgesehen, mittelfristig als paralleles Filesystem die Open-Source-Entwicklung „pvfs“ (Parallel Virtual File System) einzusetzen, deren Skalierbarkeit auf der Verwendung mehrerer Fileserver für ein Dateisystem beruht und die daher in erster Linie durch die Netzwerk-Bandbreite limitiert ist.

Die Vernetzung der Hardware in den parallelen Pools erfolgt über ein sog. Myrinet. Die 1999 verfügbare Hardware gestattet über MPI eine Übertragungsbandbreite von 35 MB/s bei einer Latenz von 25 Mikrosekunden, für den zweiten parallen Pool soll die PCI-64 Variante Myrinet 2000 mit einer Bandbreite von ca. 200 MB/s bei einer Latenz von ca. 10-15 Mikrosekunden beschafft werden.

Treibersoftware für das Myrinet steht als Open-Source im WWW zur Verfügung; der Support erfolgt in der üblichen Weise über die entsprechende Newsgruppe. Für den Benutzerbetrieb war es erforderlich, das globale AFS auch auf dem Linux-Cluster verfügbar zu machen; im Laufe des Jahres 2000 wurde hier auch seitens IBM/Transarc offizielle Unterstützung des Linux-Clients angekündigt, Ende 2000 der AFS-Source-Code sogar freigegeben, sodass AFS mit nicht zu großer zeitlicher Verzögerung auch für neuere Linux-Kernel-Versionen (2.4) verfügbar sein wird. Trotzdem bedeutet die Anpassung des Linux-Kernels an solche Besonderheiten des LRZ-Betriebs immer noch einen hohen Installations- und Testaufwand. Für die Authentifizierung am Linux-Cluster wurde zum einen die LRZ-Benutzerverwaltung auf das Cluster portiert, zum anderen speziell auf die AFS-Umgebung abgestimmte Versionen des Login-Programms Secure Shell eingerichtet.

Als Batch Queuing System wurde das Produkt Codine von der Firma Genias lizenziert; zum Betreiben von parallelen Jobs musste vom LRZ die Kopplung zwischen Codine und dem MPI-Subsystem noch „von Hand“ implementiert werden. Darüber hinaus ist es seit Herbst 2000 möglich, eine Abrechnung der in Batch-Jobs verbrauchten Rechenzeit in der auf den übrigen LRZ-Hochleistungsplattformen üb-lichen Art durchzuführen. Damit kann LRZ-seitig bei Bedarf eine Kontingentierung vorgenommen werden, um eine gerechtere Verteilung der Rechenzeit auf die Benutzer zu erzielen. Bislang waren solche Maßnahmen jedoch nur bei den Grenzwerten für den Hauptspeicher erforderlich, um eine Betriebsbeeinträchtigung durch zu groß geratene Benutzerprogramme zu unterbinden; hingegen gibt es gegenwärtig für Batch-Jobs z.B. kein Zeitlimit.

Um das Cluster mit HP OpenView VantagePoint/Operations überwachen und somit von Operateuren betreuen lassen zu können, wurde seitens des LRZ als offiziellem Beta-Test-Site mit entsprechendem Nachdruck die vorher nur für die Redhat-Distribution verfügbare Client-Version für SuSE erfolgreich getestet und inzwischen auch von HP offiziell released. Ziel ist eine Cluster-Überwachung nach dem Modell des SP2, die inzwischen auch zu großen Teilen implementiert werden konnte.