High-Performance-Computing für daheim oder mit einem Cluster aus 500 Rechnern: Mosix kann beides. Die grafische Oberfläche Mosixview sorgt dafür, dass Sie dabei den Überblick über Prozesse, Prozessoren und Performance behalten.

Zwar ist die Zeit der Großrechner und Supercomputer noch nicht vorbei, die großen Brummis haben aber verstärkt Konkurrenz bekommen: Gewöhnliche PCs steigen in ähnliche Leistungsklassen auf – und das zu einem Bruchteil der Kosten. Es müssen nur genügend CPUs parallel arbeiten.

Das kann innerhalb eines Computers stattfinden (bei Dual- oder Mehrprozessor-Systemen) oder mit Hilfe von Cluster-Software, die viele einzelne PCs zu einem Supercomputer verbindet. In so einem Cluster können 500 und mehr leistungsfähige Rechner zusammenarbeiten, dieselbe Technik eignet sich aber auch dafür, aus mehreren ausgedienten PCs daheim einen parallel arbeitenden MP3-Encoder zu basteln.

Die schwierigste Aufgabe beim High-Performance-Computing (HPC) ist es, die Last möglichst sinnvoll auf alle beteiligten System zu verteilen, also das Load Balancing. In den meisten Fällen sind die Prozesse nicht völlig unabhängig, sondern kommunizieren miteinander. Folglich hängt die resultierende Rechenleistung nicht nur von Geschwindigkeit und Anzahl der einzelnen Komponenten ab, sondern auch von der Kommunikationsgeschwindigkeit. Bei einem Cluster aus gewöhnlichen PCs ist eine schnelle Netzwerkverbindung also in jedem Fall von Vorteil.

Wandernde Prozesse

Die Hebrew University of Jerusalem entwickelt zu diesem Thema Mosix[1]. Hierbei handelt es sich um eine Erweiterung (unterliegt der GPL) des bestehenden Linux-Kernels, die automatisch die Last in einem Mosix-Rechnerverbund ausbalanciert. Ein Mosix-Cluster sieht nach außen hin aus wie ein einziges großes System mit so vielen Prozessoren, wie Computer im Cluster enthalten sind.

In einem Mosix-Cluster sind alle Rechner mehr oder weniger gleichberechtigt, es gibt also keinen Master-Server, der alle Vorgänge steuert. Dennoch ist es sinnvoll, alle Applikationen zunächst auf einem einzigen System im Rechner-Verbund zu starten. Mosix kümmert sich dann selbst um die optimale Lastverteilung. Für diese Aufgabe ist Mosix in der Lage, laufende Programme über das Netzwerk auf andere Cluster-Mitglieder zu verschieben (migrieren), ohne dass der Prozess davon etwas bemerkt.

Auf einen anderen Rechner migrierte Prozesse erscheinen weiterhin lokal in der Prozessliste des Computers, auf dem sie gestartet wurden. Tatsächlich laufen sie aber auf einer anderen Maschine, deren Rechenleistung sie nutzen. Mosix entscheidet anhand verschiedener Informationen, die es von jedem Cluster-Rechner erhält, welchen Prozess es auf einen anderen, vielleicht weniger ausgelasteten Computer verschiebt. In diese Entscheidung fließen Daten wie die Geschwindigkeit, Auslastung oder die Anzahl an CPUs ein.

Cluster@home

Mosix-Cluster sind an vielen Universitäten und in der HPC-Welt verbreitet, aber auch der Linux-Anwender zu Hause kann seine Altlasten durchaus sinnvoll und preiswert zu einem eigenen Supercomputer zusammenbauen. Selbst der verstaubte 486er oder Pentium I kann beispielsweise an der Umwandlung der heimischen CD-Sammlung ins MP3-Format mitarbeiten.

Mit Hilfe des Boot-ROMs der Netzwerkkarte oder einfach mit einer simplen Bootdiskette kann jeder PC in einem Netzwerk von einem NFS-Server booten. Die Festplatte in solchen Diskless Clients bleibt unberührt, so dass sich der Computer auch wieder schnell mit dem vorhandenen Betriebssystem auf der Festplatte starten lässt[2],[3].

Diskless Client

Die Disk-Images sind sozusagen Mini-Linux-Installationen, die in einem Verzeichnis auf dem NFS-Server liegen (normalerweise »/tftpboot/ Clinet-IP«). Dieser Server ist zusätzlich noch so konfiguriert, dass er auf RARP- und DHCP-Requests der Boot-Clients antwortet. Er gibt seinen Clients damit beim Booten unter anderem ihre IP-Adresse mit. Der Mosix-Kernel für die Bootdiskette benötigt folgende Optionen:

CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
CONFIG_IP_PNP_BOOTP=y
CONFIG_IP_PNP_RARP=y
CONFIG_ROOT_NFS=y

Ist er mit diesen Optionen konfiguriert und kompiliert, dann fragt der Kernel beim Booten im Netzwerk unter anderem nach seiner eigenen IP-Adresse. Er nutzt dazu das Reverse Address Resolution Protocol (RARP), das Bootstrap Protocol (BOOTP) und das Dynamic Host Configuration Protocol (DHCP). Hat er seine Konfiguration erhalten, fährt er mit Hilfe des freigegebenen Verzeichnisses des NFS-Servers hoch. Viele Linux-Distributionen enthalten auch Programme wie LUI oder die Diskless Cluster Tools, mit deren Hilfe die Konfiguration einfach vorzunehmen ist.

Die besonderen Cluster-Fähigkeiten sind im Standardkernel noch nicht enthalten, Mosix enthält dafür ein Kernel-Patch. Dazu gesellen sich noch einige Kommandozeilen-Utilities, etwa zur Überwachung oder zum Tuning. Wichtig ist vor allem, die passende Kernelversion zur jeweiligen Mosix-Version zu benutzen. Die README-Datei sagt gleich in der Überschrift, für welche Kernelversion das Patch gedacht ist. Sie erklärt auch die Installation und Konfiguration von Mosix, die sowohl per Menü als auch manuell möglich ist.

Mosix installieren

Nach der Installation des neuen Kernels muss noch die Mosix-Konfigurationsdatei »/etc/mosix.map« angelegt werden, die alle Cluster-Computer auflistet. Für unseren Fünf-Rechner-Cluster sieht die Datei folgendermaßen aus:

1 192.168.100.1 1
2 192.168.100.2 1
3 192.168.100.3 1
4 192.168.100.4 1
5 192.168.100.5 1

In der ersten Spalte sind die Mosix-Computer der Reihe nach durchnummeriert. Dann folgen die IP-Adresse des jeweiligen Knotens und eine Eins. Die letzte Ziffer in jeder Zeile zeigt, wie viele Computer sich im IP-Bereich dieses Rechners befinden. Im Beispiel beträgt die IP-Range immer »1«, jedes System ist also in einer einzelnen Zeile konfiguriert. Bei direkt aufeinander folgenden IP-Adressen dürfen die IP-Ranges aber auch größer sein, dieselbe Mosix-Konfiguration passt damit in eine einzelne Zeile:

1 192.168.100.1 5

Die letzte Ziffer steht nun für fünf aufeinander folgende Hosts. Das klappt nur mit IP-Adressen, bei Hostnamen ist diese Vereinfachung nicht möglich.

Hat ein Host mehr als eine IP-Adresse (etwa weil er mehrere Netzwerkkarten hat), dann können die zusätzlichen Adressen als Alias eingetragen werden: Die Knoten-Nummer bleibt gleich und an Stelle der IP-Range steht das Schlüsselwort »ALIAS«. Wichtig ist, dass diese Datei auf allen Cluster-Knoten identisch vorliegt. Nur dann kann Mosix die Topologie des Rechnerverbunds korrekt erkennen.

Neu: Mosixview

Mit »mosixctrl« enthält die Cluster-Software schon ein Kommandozeilen-Tool zur Administration. Wer grafische Tools bevorzugt, wird bei der GPL-Software Mosixview fündig[4]: Dieses neue GUI zeigt die Prozesse übersichtlich an, unter anderem mit der Last, die sie erzeugen (Abbildung 1). Es kann die wichtigsten Parameter der Cluster-Knoten (Abbildung 2) und der Prozesse verwalten, enthält einen Logfile-Analyzer für den benutzten und verfügbaren Speicher sowie ein History-Werkzeug, mit dem sich der Weg eines Prozesses durch den Cluster nachvollziehen lässt. Außerdem hilft ein Advanced-Execution-Dialog (Abbildung 3) beim Start neuer Tasks.

Mosixview installiert sich mit Hilfe des »setup«-Skripts fast automatisch. Dieses Skript erwartet das Qt-Installationsverzeichnis als Argument:

./setup /usr/lib/qt

Mosixview kompiliert und installiert daraufhin alle benötigten Komponenten. Alternativ zum Source-Tarball liegen auch RPM-Pakete für einige Linux-Distributionen vor:

rpm --install mosixview-1.0.suse72.rpm

Der Mosixview-Client (»/usr/bin/mosixview_client«) sollte jetzt noch auf jeden Cluster-Computer kopiert werden, um volle Funktionalität zu gewährleisten. Der Mosix-Cluster ist nun fertig installiert und konfiguriert und lässt sich mit dem Mosix-Init-Skript starten:

/etc/init.d/mosix start

Den erfolgreichen Start können das Mosix-Utility »mon« oder Mosixview überprüfen.

Abbildung 1: Das Hauptfenster von Mosixview 1.0 zeigt die an dem Cluster beteiligten Rechner übersichtlich an. Bei jedem Cluster-Knoten ist die Last zu erkennen.

Abbildung 2: Konfigurationsdialog für einen Cluster-Rechner. Die Schalter legen fest, welche Prozesse der Knoten wann auf einen anderen Computer migriert.

Abbildung 3: Der Advanced-Execution-Dialog startet Programme im Cluster und gibt ihnen die passenden Parameter mit auf den Weg.

Verteilte Software

Normalerweise ist speziell parallelisierte Software notwendig, um die Leistung eines Rechnerverbunds auszunutzen. Vorhandene Software muss dazu mühsam in kleine, möglichst unabhängig voneinander zu erledigende Probleme zerlegt werden, damit sie sich auf die einzelnen System verteilen lässt.

Mit Mosix hat man es da etwas einfacher, denn das Programm kümmert sich selbst um die optimale Verteilung der Rechenlast und der Prozesse. Der Leitsatz ist “Fork and forget”: Startet ein neuer Prozess irgendwo im Cluster, dann entscheidet Mosix von sich aus, welcher Computer den Prozess berechnet (ausführt). Diese Prozessmigration ist völlig transparent. Der migrierte, also auf einen anderen Rechner verschobene Prozess erscheint weiterhin lokal in der Prozessliste und wird dennoch remote berechnet.

Bladeenc parallel

Eine Anwendung, die sehr gut in einem Mosix-Cluster funktioniert, ist beispielsweise das parallele Umwandeln mehrerer Audio-Dateien in das MP3-Format – um der eigenen CD-Sammlung auch im MP3-Player lauschen zu können, ist dieser rechenintensive Schritt notwendig. Das KDE-Programm Krabber grabbt die Dateien von der CD und startet für jedes Musikstück einen Bladeenc-Prozess. Mosix verteilt die Encoder-Instanzen anschließend auf die verfügbaren Rechner. Dazu aber später mehr.

Natürlich können die in der Mosix-Software enthaltenen Tools das automatische Load-Balancing weitreichend beeinflussen. Nicht nur Single-Threaded-Programme, auch nahezu jede Multi-Threaded-Applikation kann Mosix über beliebig viele Computer verteilen. An die Grenzen stößt das Verfahren aber bei Programmen, die Shared Memory nutzen (wie Apache oder MySQL): diese kann Mosix nicht verschieben.

Abbildung 4: Die Konfiguration von Krabber. Rechts unten neben der Titelliste ist die Anzahl der Encoder eingestellt, die Krabber für das Konvertieren in MP3 parallel startet.

Durchblick

Eine Übersicht über den gesamten Cluster erzeugt die grafische Oberfläche Mosixview. Mit ihr lässt sich unter anderem die Konfiguration des Rechnerverbunds einstellen und im laufenden Betrieb verändern. Beispielsweise stellt ein einfacher Schieberegler die Priorität ein, mit der einzelne Cluster-Knoten an einer Applikation arbeiten.

Eine eigene Prozess-Box, der Mosixview-Client (Abbildung 5), dient zur Steuerung einzelner Prozesse, etwa um sie gezielt auf einen anderen Rechner im Cluster zu verschieben (migrieren). Die zweite Spalte (»n#«) in diesem Fenster zeigt an, auf welchem Knoten der Prozess gerade läuft. Eine Fünf in dieser Spalte besagt, dass der Computer mit der Mosix-ID »5« gerade an dem Prozess arbeitet. Solche migrierten Programme stellt Mosixview mit einem grünen Icon dar. Ein rotes Symbol und eine Null als aktuellen Knoten erhalten lokale Prozesse, die nicht migriert sind.

Nach einem Doppelklick auf einen der Prozesse erscheint eine weitere Dialogbox, mit der sich einzelne Parameter des Prozesses einstellen lassen. Hier kann man auch das laufende Programm auf einen anderen Cluster-Computer verschieben oder die Prozess-Priorität (Nice Level) einstellen.

Langzeitberechnungen überwacht ein Collector-Daemon: Der Mosixcollector sammelt Last- und Memory-Daten des Clusters und speichert minütlich die Prozessliste. Die angefallenen Daten bereiten dann Mosixload, Mosixmem und Mosixhistory grafisch auf, um so die Abläufe im ganzen Cluster zu beobachten.

Abbildung 5: Die Prozess-Box des Mosixview-Clients zeigt an, auf welchem Computer das Programm tatsächlich läuft (Spalte »n#«). An dem grünen Icon sind migrierte Prozesse schnell zu erkennen.

Mosix im Einsatz

Wie gut funktioniert das nun in der Praxis? Als Test-Cluster diente ein Mosix-Cluster mit fünf Knoten, der auch zur Entwicklung von Mosixview genutzt wird. Dieser Rechnerpark besteht aus unterschiedlicher Hardware vom P I mit 166 MHz bis zum P III mit 1 GHz. Als Eigenbau-Linux-Cluster demonstriert er auch, wie gut sich relativ alte Hardware für einen Mosix-Cluster einsetzen lässt.

Ein P III mit 1 GHz dient als DHCP- und NFS-Server für die Boot-Images der Diskless-Clients. Eine Bootdiskette mit Hardware- und Mosix-Unterstützung genügt bereits, um alle Clients zu booten. Nach dem Erkennen der Netzwerkkarte erhalten sie per DHCP eine IP-Adresse, ihr gesamtes Dateisystem kommt vom NFS-Server. Auf einem System mit CD-ROM-Laufwerk wurde noch Krabber installiert, ein Audio-Grabber und -Konverter für KDE.

Als MP3-Encoder kam Bladeenc zum Einsatz. Krabber wurde so eingestellt (siehe Abbildung 4), dass es bis zu sechs Encoder-Prozesse gleichzeitig startet. Normalerweise lastet das auch ein schnelles System bis an seine Grenzen aus (siehe Abbildung 7). Mosixview überwacht den Test mit unserem Cluster, der Mosixcollector läuft dazu auf dem Rechner, auf dem auch Krabber arbeitet.

Mit Checkpoints (»mosixcollector -n«) lassen sich wichtige Zeitpunkte markieren. Der Mosixview-Loganalyzer stellt sie bei der grafischen Aufarbeitung mit einer blauen Linie dar. Der erste Checkpoint wurde im Test zum Startzeitpunkt des Encodier-Vorgangs gesetzt, der zweite am Ende.

Nach dem Einlesen des ersten Titels startet der erste Bladeenc-Prozess. Er migriert nach kurzer Zeit auf den am besten verfügbaren Rechner und wird von diesem Computer berechnet. Die Latenzzeiten lassen sich natürlich konfigurieren, normalerweise sind es zehn bis zwanzig Sekunden.

In unserem Testszenario wurden alle Prozesse auf einem Rechner gestartet (dem Knoten mit der Nummer »3«). Krabber liest die Audio-CD aus und startet die Encoder-Programme, die nach kurzer Zeit auf andere Cluster-Mitglieder wandern. Der Krabber-Rechner ist damit beschäftigt, die CD auszulesen, während alle anderen Computer sich um die MP3-Umwandlung kümmern. Die fertigen MP3-Files landen wieder auf dem Krabber-Rechner, es ist also kein gemeinsam gemountetes Filesystem erforderlich. Nur die Berechnung des Prozesses wird migriert, Mosix kümmert sich darum, dass die Ergebnisse wieder auf den Startrechner zurückkommen.

Abbildung 6: Grafische Auswertung des Tests mit Mosixload. Die blauen Linien kennzeichnen den Startzeitpunkt und das Ende des gesamten Ablaufs. Krabber läuft auf Knoten »3«, die anderen vier Computer berechnen die MP3-Files.

Abbildung 7: Ohne die Hilfe des Clusters stößt unser Test an die Grenzen eines einzelnen Computers: 100 Prozent CPU-Last und eine Load über 8.

Ergebnisse

Um vergleichbare Ergebnisse zu erhalten, haben wir den Test in zwei Varianten durchgeführt: Einmal mit einem einzelnen Computer und dann mit einem Fünf-Knoten-Cluster. In beiden Fällen wurden zwölf Titel einer Beispiel-CD in MP3 umgewandelt. Der Testlauf begann auf einem P III/700, danach beteiligten sich vier zusätzliche Mosix-Computer an der Problemlösung.

Der Cluster mit fünf Rechnern schafft es, die zwölf Titel in 21 Minuten ins MP3-Format zu wandeln (Abbildung 6). Für dieselbe CD benötigte der einzelne Rechner ganze 52 Minuten. Obwohl im Cluster auch recht alte Hardware (Pentium 166) zum Einsatz kam und das Grabben der CD nur auf einem einzelnen Rechner läuft, sprechen die Resultate für sich.

Fazit

Schnellere Datenverarbeitung lässt sich also nicht nur mit höherer Hardware-Geschwindigkeit erzielen. Intelligente, parallele Software wird in Zukunft vielleicht auch für den Linux-Anwender immer interessanter, wenn sie für ihn einfach zu benutzten und transparent ist, wie dies Mosix vorführt. In unserem Test konnten wir sogar den Pentium-Emulator Bochs mit laufendem Windows auf einen anderen Rechner verschieben. Wir sind gespannt, wann die erste parallelisierte Software für DVD-Video-Konvertierung erhältlich ist. (fjl)