Manege frei

Inhaltsverzeichnis

Zum 250sten Mal strahlte der WDR am 5./6. Dezember seinen Computer-Club aus. Eine solche Gelegenheit wollten sich Linux-Anhänger um Tom Schwaller vom Linux-Magazin und den Berliner Sebastian Hetze nicht entgehen lassen. Sie trommelten in Newsgroups und Mailinglisten Interessierte für den größten jemals gebauten Linux-Cluster zusammen.

Eine Zweierpotenz mußte es sein, und so entschied man sich für 512 Rechner, die über ein 100-MBit-Ethernet verbunden sein sollten. Viele Computer und die gesamte Infrastruktur (Switches et cetera) stammten von Sponsoren, eine Liste enthält der Kasten ‘Cluster-Sponsoren’. Privatpersonen konnten sich mit ihren Rechnern ebenfalls beteiligen. Zusätzliche Spannung trug die Tatsache bei, daß es sich nicht um ein homogenes Netz handelt: Neben der Mehrheit von Intel-Maschinen waren 60 Alphas beteiligt. Getauft wurde das Kind auf den Namen CLOWN: CLuster Of Working Nodes.

Viel Hardware nimmt zwar viel Platz weg, ist aber nicht übermäßig telegen. Es mußte also Software her, die die Leistungsfähigkeit eines Clusters demonstrieren konnte. Damit diese Spezialprogramme nicht der bereits installierten Software in die Quere kommen, erstellte Florian Lohoff zunächst eine spezielle Distribution, die sich als Datei auf der Festplatte installieren läßt (siehe ‘Was auf den Linux-Systemen lief’).

Zur Koordinierung der Verteilung von Aufgaben zwischen den Rechnern diente PVM (Parallel Virtual Machine). Zusätzlich zu den Modifikationen an der eigentlichen Distribution sind zwei Anwender erforderlich (pvm34 und povray), die dazu dienen, die Applikationen laufen zu lassen. pvm34 soll das Experimentieren mit der aktuellen Entwicklerversion 3.4beta7 von PVM ermöglichen. Im Heimatverzeichnis von pvm34 sind ein pvm3d vorhanden sowie der Beispiel-Client mtile zur verteilten Berechnung von Apfelmännchen. Unter dem Anwender povray ist die aktuelle Version von povray (3.02) zu finden. Sie ist um einen Isosurface-Patch erweitert, der nötig ist, um einen von der Uni Konstanz bereitgestellten Film zu berechnen. Auf dieser Basis zeigte Povray seine Leistungsfähigkeit beim Rendering verschiedener Filme.

Für die parallele Berechnung der Filme auf Frame-Basis wird povray für jedes einzelne Bild aufgerufen. Die Lastverteilung organisiert ein von Roger Butenuth (Uni Paderborn) für diesen Zweck erstelltes Programm, das auf RPC basiert. Die Entscheidung für RPC fiel wegen seiner Robustheit und des verbindungslosen Protokolls (UDP). Bei TCP hätte der Lastverteilungsserver mit 512 offenen Verbindungen kämpfen müssen.

Das Programm ist für beliebige andere Aufgaben einsetzbar, die nach dem Master-Worker Schema arbeiten. Zur Robustheit trägt bei, daß man es bei einem Absturz mit den Informationen aus einer Zustandsdatei wieder neu starten kann. Aufträge, die ein Client nicht rechtzeitig abliefert, schickt der Server zu einem anderen Rechner. Die Kommandozeilen für die Clients erzeugt ein awk-Script auf dem Server. Es muß auf Eingabe der Arbeitspaketnummer nur mit einer Kommandozeile für dieses Paket antworten. Nach der Fernsehnacht wird der Lastverteiler unter der GPL veröffentlicht.

Um Universales kümmerte sich das Programm Cactus, entwickelt vom Potsdamer Albert-Einstein-Institut. Es löst die Einstein-Gleichungen, das sind zehn nichtlineare, gekoppelte hyperbolisch-elliptische partielle Differentialgleichungen. Sie beschreiben Gravitationswellen, Schwarze Löcher, Neutronensterne et cetera und gehören zu den kompliziertesten in der mathematischen Physik. Cactus ist modular aufgebaut und läuft auf verschiedenen Supercomputer- und Unix-Maschinen. Aufgrund von Netzproblemen skalierte Cactus auf dem Cluster nicht so gut wie erwartet - so lag beispielweise der Skalierungsfaktor bei 20 Knoten nur bei 0,78. Während der Computernacht berechnete Cactus auf 32 Knoten lineare Gravitationswellen, zur Visualisierung der Ergebnisse diente IDL [1].

Neben der Beschaffung von Hard- und Software entstanden einige Schwierigkeiten durch die schiere Menge der Maschinen: Für Stromversorgung und Abfuhr der entstehenden Wärme war zu sorgen sowie eine hinreichend leistungsfähige Infrastruktur für das Netzwerk zu beschaffen. Zur Hitzebekämpfung mußte schließlich noch die Paderborner Feuerwehr einspringen: Sie verlegte große Plastikrohre, die Winterluft ins Gebäude bliesen und die Temperatur so im erträglichen Bereich zwischen 30 und 32 Grad hielten (siehe Foto).

Für einen Eintrag im Guinness-Buch der Rekorde dürfte es allemal reichen: insgesamt waren bis zu 570 Knoten im Cluster aktiv, von denen bis zu 520 im Verbund als virtueller Linux-Supercomputer an Filmen oder mathematischen Problemen rechneten. Auch in Sachen Eintrag in die Liste der Top-500 des Supercomputing stehen die Aktien nicht schlecht. Nach einigen Anpassungsarbeiten lief auf einem Alpha-Sub-Cluster mit 48 Knoten der dazu nötige Linpack-Benchmark durch. Die erzielten Ergebnisse lassen vorbehaltlich einer Verifizierung eine Plazierung um Rang 250 erwarten. Details dazu wird iX in der nächsten Ausgabe liefern. Anmerkung am Rande: die Computernacht war nach der Fußball-WM die zweitgrößte WDR-Produktion des Jahres - ein Rahmen, der dem Cluster-Event gerecht wurde.

Literatur

[1] Dieter Frieauff; Malen mit Zahlen; Objektorientierte Datenvisualisierung mit IDL 5; iX 11/97, S. 98 ff.

Mehr Infos

Das letzte Mal

Fernsehen kann Strafe sein. Dem Linux-Cluster sei die kostenlose Werbung gegönnt - aber wer erträgt diesen WDR-Computerclub nun eigentlich seit über zehn Jahren? Da strapsen sich zwei Moderatoren ab, die uninspirierter, langweiliger, desinteressierter und ahnungsloser kaum vorstellbar sind. Sie sondern Weisheiten ab wie "Aus der Raumfahrt ist der Computer nun nicht mehr wegzudenken", "die 25 Buchstaben des Alphabets" oder "Ja, das sieht sehr schön aus, machen Sie mal weiter so" zu einem Kalligraphen, von dem keiner weiß, warum er in dieser Sendung herumsaß.

Die Crème de la Crème der deutschen Hochschulforschung schlägt sich in Paderborn die Nacht um die Ohren, um einem Journalisten maximal 90 Sekunden Antworten zu geben, die diesen offenbar nicht interessieren. Kein roter Faden, kein Zusammenhang, statt dessen Erklärungen für das Publikum, wie schwer die eigene Arbeit und wie groß die Begeisterung über eben diese Arbeit bei eben diesem Publikum sei - die Inkarnation des Loopback-Device.

Peinlich und uninteressant, das alles. Eine Entschuldigung wert wäre jedoch das Benehmen Wolfgang Backs gegenüber dem Kollegen von der Deutschen Welle: Vorgestellt mit seinem Namen und dem Zusatz "Chinese", mußte er Backs alberne Nachäffung seiner Muttersprache auf offener Bühne ertragen.

Wohl dem, der hinreichende Alkoholvorräte bereitgestellt hatte - mit zunehmender Umnebelung ließ sich das Ganze wenigstens bis fünf Uhr morgens ertragen.

Was auf den Linux-Systemen lief

Was auf den Linux-Systemen lief

Notwendig war ein schnelles, einfaches Installations-Procedere, das einige Bedingungen erfüllen mußte: Größtmögliche Flexibilität in bezug auf Hardware, Software und Zeitpunkt der Integration in den Cluster, die Installation von über 500 Rechnern sollte in weniger als 12 Stunden möglich, sowie die Kernel-Hardwarekonfiguration vor der Integration in den Cluster überprüfbar sein. Darüber hinaus sollte die Installation möglichst viele potentielle Probleme im Vorfeld eliminieren.

Im wesentlichen besteht die Cluster-Distribution aus einem glibc-basierten Debian-2.0-Linux. Sie enthält nur das Allernötigste, dies läßt eine Installation in circa 20 MByte zu. Überflüssige Pakete wie Zoneninfos, Keyboard-Mappings et cetera wurden entfernt. Als Kernel kommt ein 2.0.36 mit dem unten beschriebenen loop-root-Patch zum Einsatz, die 2.1.x-Kernel haben die für einen solchen Event nötige Stabilität noch nicht erreicht. Eine von der Debian stammende Rescue-Disk fungiert als Boot-Diskette, sie enthält Binaries wie ls, mount, umount, mke2fs.

Da die Installation auf den meisten Rechnern (< 64 MByte Speicher) den Rahmen einer Ramdisk sprengen würde, war klar, daß die Platte als Medium gebraucht würde. Nun galt es, die Installation so flexibel zu gestalten, daß sich ohne Hard- und Softwaremodifikationen an den Zielsystemen eine funktionsfähige Installation booten ließ. Als mögliche Zielsysteme für eine Installation kamen zunächst ext2, umsdos, ramdisk und loop-root in Frage. UMSDos fiel wegen einiger Kernel-Bugs weg, was dank loop-root jedoch keine Funktionseinbußen mit sich brachte.

Von den genannten Installationsmöglichkeiten ist loop-root die einzige, die nicht jeder Standardkernel bietet. Es existiert eine Liste inoffizieller Kernel-Patches, auf der sich auch ein loop-root-Patch findet. loop-root bedeutet nichts anderes, als daß sich das Root-Filesystem in einer Datei auf einem anderen Dateisystem wie Ext2 oder MS-DOS befindet und zur Bootzeit via /dev/loop gemountet wird. Das ermöglicht eine Installation auf einer MS-DOS- oder Ext2-Partition, ohne deren Inhalt zu modifizieren, beziehungsweise durch Hinzufügen von nur einer Datei.

Zur Wahrung der Flexibilität bei der Hardware befinden sich alle Netzwerkkartentreiber als Module auf der Diskette. Dieses verhindert einen Dead-Lock beim Booten durch fälschliches Autoprobing und erlaubt trotzdem, alle Karten zu unterstützen. Darüber hinaus sollte die Möglichkeit bestehen, noch am Abend vor der Veranstaltung die eigentliche Distribution zu ändern, so daß nur eine Netzinstallation übrig blieb.

Damit die benötigte Zeit pro Rechner möglichst gering bleibt, sollte im Vorfeld die Konfiguration der Hardware bekannt sein. Sämtliche Einstellungen wie Installationsziel, IP-Adressen, NFS-Server, zu ladende Module inklusive IRQ- und IO-Settings liegen deshalb auf der MS-DOS-formatierten Diskette als ASCII-Datei vor und lassen sich bei der Einlieferung des Rechners via mtools leicht modifizieren.

Unterschiede zur Standard-Distribution

Das Interessanteste an der Diskette ist das in der Ramdisk initrd (root.bin) vorhandene Script linuxrc. Es lädt in Abhängigkeit der auf der Diskette vorhandenen Config-Dateien ip.cfg, dst.cfg und mod.cfg die entsprechenden Module, hängt Dateisysteme ein, konfiguriert Interfaces, holt via NFS die restliche Installation, installiert sie auf dem Zieldateisystem und bootet dort weiter.

Beim im Kernel verwendeten loop-root-Patch handelt es sich um eine erweiterte Version des auf linuxhq.com zu findenden. Der Original-Patch ließ es nicht zu, zur Laufzeit der initrd den loop-root-Namen, also den Namen der Loop-Datei, zu setzen und damit loop-root zu aktivieren (modifizierter Patch [ftp://move.mediaways.net/pub/cluster/] für 2.0.36- und 2.1.122-Kernel). Er ergänzt das /proc-Dateisystem um /proc/sys/kernel/loop-root-name. Die Distribution wurde auf das Allernotwendigste zusammengeschnitten. Zusätzlich wurden rshd, und rlogind so modifiziert, daß keinerlei DNS-Anfragen und keinerlei Authentifizierung über ~/.rhosts und /etc/hosts.equiv erfolgen. Dies dient zum einen dazu, die Zeit zum Anmelden zu minimieren, zum anderen Fehlerquellen wie geänderte IP-Adressen der Master-Console(n) oder nicht vorhandene DNS-Server zu eliminieren. Das login-Binary wurde so modifiziert, daß es einen Root-Login auf allen ttys unabhängig der /etc/securetty zuläßt. Diese Modifikationen machen den einzelnen Node zwar angreifbar, allerdings ist der Cluster nicht dazu gedacht, mit dem Internet verbunden zu werden (Patches [ftp://move.mediaways.net/pub/cluster/] gegen die Debian Source Packages).

Weiterhin sind einige Boot-Scripts ergänzt oder sogar neue hinzugekommen. Zur Bootzeit wird eine Standardinstallation vom NFS-Server geholt, die nachträglich personalisiert werden muß. Hierfür werden anhand der auf eth0 konfigurierten IP-Adresse /etc/hostname und /etc/hosts ergänzt beziehungsweise erstellt, um zumindest dem Rechner das Auflösen seiner eigenen Adresse zu ermöglichen.

Weiterhin muß nach dem fsck der Root-Partition (nicht vorher, wie üblich) dafür gesorgt werden, daß ausreichend Swap vorhanden ist. Hierfür wird via fdisk auf allen bekannten Platten nach bestehenden Swap-Partitionen gesucht und diese falls vorhanden aktiviert. Ist danach noch immer nicht genügend Swap vorhanden, erstellt das Bootup-Skript (außer bei Ramdisk-Install) ein Swapfile im Wurzelverzeichnis der Installation oder auf /bootfs, wo im loop-root Fall das Dateisystem mit der Loop-Datei eingehängt ist.

Distributionsfrage: Warum Debian?

Theoretisch läßt sich jede Linux-Distribution für eine solchen Einsatz modifizieren. In erster Linie bestimmte das Wissen um Debian die Wahl der Distribution. Daneben hat Debian folgende Vorteile: Sämtliche Modifikationen der Pakete (nicht contrib oder non-free) lassen sich ohne lizenzrechtliche Bedenken wieder veröffentlichen, sie bietet einfache, leicht zu modifizierende Boot-Skripte, läßt sich extrem verkleinern (auf unter 16 MByte) und hält sich strikt an den Linux-FSSTND (File System Standard).

Die Installation (vom Einlegen der Diskette bis zum Login-Prompt) dauert in einer etwas älteren Version 105 Sekunden. Dadurch daß zuätzlich PCMCIA-Support aufgenommen wurde, wird sich die Zeit um 10 bis 20 Sekunden verlängert haben. Diese Werte gelten für die Installation auf einer ext2-Partition mit 200 MByte.

Benchmarks für die loop-root-Installation liegen derzeit nicht vor, allerdings spricht der Autor des Original-Patches von nahezu identischer Performance von ext2-loop-ext2 und nativem ext2. Loop-root-ext2 auf MS-DOS soll allerdings nur halb so schnell sein, was vermutlich an der schlechten Performance des mmaps bei diesem Dateisystemen liegt.

Cluster-Sponsoren

Cluster-Sponsoren

Ein Projekt dieser Größenordnung wäre in der Kürze der Zeit ohne die Unterstützung von Firmen sicher nicht realisierbar gewesen. Neben den unten aufgeführten Hauptsponsoren gilt dies aber auch für die über 200 Linux-Enthusiasten, die weder die Zeit noch das schlechte Wetter scheuten, ihre Rechner nach Paderborn zu bringen, damit die angepeilte Knotenanzahl für den Cluster realisiert werden konnte. Hierbei dürfen auch die fast 100 Helfer nicht unerwähnt bleiben. Sie sorgten in vier Teams à drei Schichten für einen fast reibungslosen Verlauf der Veranstaltung. Es sei noch mal ausdrücklich darauf hingewiesen, daß der Linux-Cluster ehrenamtlichen Charakter hatte - auch die beteiligten Firmen stellten ihre Dienste ohne Berechnung bereit.

Größten Anteil am Gelingen des Linux-Cluster hatte die Universität Paderborn. Neben umfangreichen Räumlichkeiten und der Energieversorgung stellte sie dem Cluster mehr als 30 Rechner (unter anderem 20 PII/400 mit 128 MByte RAM) sowie personelle Unterstützung zur Verfügung. Als weiterer Hauptsponsor präsentierte sich Hewlett Packard. Er stellte ein leistungsfähiges Netz inklusive Installation und Wartung durch HP-Techniker bereit. Dazu kamen insgesamt 17 Switches der ProCurve-Serie im Gesamtwert von circa 400 000 DM zum Einsatz. Herzstück waren sieben Modelle 8000M, die - über HPs Switch-Meshing-Technik via Glasfaser vermascht - eine Backbone-Schaltleistung von 9 GBit/s realisierten. Insgesamt standen dem Cluster über 600 10/100-Ports mit Autosensing zur Verfügung. Zusätzlich sorgte HP mit Geräten und seinem OpenView für die Überwachung des Cluster-Netzes. Bei den Rechner-Sponsoren stand Peacock zuerst auf der Matte. Die Braunschweiger hatten spontan eine Kleinserie mit 50 Maschinen aufgelegt und nach Paderborn geschickt.

Andere Hersteller und Privatpersonen folgten, aus Platzgründen hier eine tabellarische Auflistung (in zeitlicher Reihenfolge):

Hardware
Quant-X/Samsung	50 Alphas mit 667-MHz-CPU und 256 MByte RAM, incl. Personal
Siemens	10 Intel Workstations, 1 vierfach-Xeon-Server mit 2 GByte RAM
Maxdata/Seagate	2x vierfach-, 1x Dual-PII-Xeon/400 MHz, 2x1 GByte/1x768 MByte RAM, ICP Vortex Raid-Controller, zus. ca. 450 GByte Plattenplatz
Jolo Data	Diskettenkopierwerk inklusive einige Hundert Disketten
Planet Insomnia	hatte eine Netz-Fallbacklösung für 1000 Maschinen angeboten, diese wurde später durch HP ersetzt.
Uni Rostock/debis AG	Mini-Cluster mit 1xP5 und 16xDual-P5 mit 24/32 MByte RAM
SEH GmbH	128 PII/350 mit 64 MByte RAM auf Rollwagen, zusätzliche Rollwagen vereinfachten den Transport der angelieferten Privat-PCs erheblich
LANetixx	4 PC (PII/300-128MByte, PII/266-96MByte, PII/266-64MByte, P6/180-128MByte)
Packet Engines	Gigabit-Ethernet-Karten für die NFS-Server
DeTeCSM	10 PII/300, 10 P5/166 mit je 64 MByte RAM
LunetIX	1 Alpha-Rechner mit 1,5 GByte RAM als Backbone-Server
Creaso	stellte die benötigten IDL-Lizenzen für die Visualisierung bereit
Sixt	spendierte der Augsburger Linux-User-Group einen Kleinbus für den Transport ihrer Rechner nach Paderborn

Finanzielle Sponsoren
Syskoplan	2000 DM
Arthur Andresen	2000 DM
Vereinigte Verlagsanstalten	500 DM
Jörg Fehlmann	500 DM

Darüber hinaus stifteten einige Unternehmen Preise, die in der Nacht unter den Helfern und Rechnerlieferanten ausgelost wurden (Details hierzu). (avr)