Einigkeit macht stark

Preiswerte Hochleistungsrechner mit Clustern

Trends & News | Trend

Ob Number Cruncher oder hochverfügbarer Server: Mit dem Versprechen von High-End-Funktionen für wenig Geld erobern sich Cluster immer mehr Einsatzbereiche. Ein Blick auf die dahinter stehende Technik zeigt die Möglichkeiten, aber auch Grenzen von Clustern auf.

Aufmacher

Cluster sind in - die Idee ist ja so bestechend: Man vernetzt einfach einige billige PCs von der Stange, und schon hat man die Rechenleistung eines Supercomputers. Der dient dann tagsüber als leistungsfähiger Internet-Server und als hochverfügbarer Datenbankserver für die Firma; nachts kann der Sysadmin damit so esoterischen Hobbys wie dem Simulieren von Atombombenexplosionen nachgehen.

Das Ganze ist ein einfaches Rechenexempel: Ein moderner Pentium-III mit 800 MHz bringt im Linpack eine Rechenleistung von rund 200 MFLOPS (Millionen Fließkommaoperationen pro Sekunde). Die Top 500 der Supercomputer [1] starten zurzeit bei gut 40 GFLOPS. 250 aktuelle PCs kommen zusammen also theoretisch auf eine Rechenleistung, die schon für eine ordentliche Platzierung in den Top 500 reichen würde - bei einem sechsstelligen Betrag für die Hardware, wo man für ‘echte’ Supercomputer viele Millionen anlegen muss.

Dieselbe Rechnung lässt sich für andere Einsatzbereiche aufmachen. Wo ein gut ausgebauter PC als Webserver einige hundert Anfragen pro Sekunde beantwortet, schaffen zehn PCs einige tausend Requests/s - und sind dabei deutlich billiger als ein ähnlich leistungsfähiger ‘großer’ Server etwa von Sun. Und nebenbei gewinnt man mit einem Cluster auch noch Ausfallsicherheit: Geht einer der Rechner im Cluster kaputt, müssen die anderen eben etwas mehr arbeiten, bis der Schaden behoben ist. Fällt hingegen der eine große Server aus, steht das Internet-Business erst mal still.

Gerade PC-Hardware ist konkurrenzlos billig, keine andere Plattform liefert so viel Rechenleistung fürs Geld. Egal, in welche Leistungsklasse man vorstoßen möchte: Die entsprechende Anzahl PCs ist immer billiger als ein einzelner Rechner mit der gewünschten Power. Nicht zuletzt deshalb finden sich immer mehr Rechencluster in der Liste der 500 schnellsten Computer und verbergen sich hinter immer mehr Internet-Adressen Server-Farmen (siehe [#kasten Glossar]). Und das Beste: Reicht die Leistung nicht mehr aus, hängt man einfach ein paar zusätzliche Rechner in den Cluster.

Aber ganz so glatt geht die Rechnung in der Praxis natürlich nicht auf. Um von einem Cluster zu profitieren, muss sich die eingesetzte Anwendung auf mehrere vernetzte Rechner verteilen lassen. Das ist relativ einfach bei unabhängigen Rechenaufgaben wie beispielsweise dem Rendern von Filmen: Jeder einzelne Knoten erhält das 3D-Modell eines Bildes, rendert das Bild, liefert es ab und erhält die Daten des nächsten Bildes. Je mehr Rechenknoten im Cluster, desto schneller ist der Film fertig.

Auch ein stark ausgelasteter E-Commerce-Server kann sich gut aufteilen lassen: Dann läuft beispielsweise der http-Server auf einem Rechner, die dahinter stehende Datenbank auf einem zweiten, und ein dritter Computer verknüpft die Bestellungen der Kunden mit dem Warenwirtschaftssystem.

Deutlich vertrackter wird die Angelegenheit jedoch, wenn die zu bewältigende Aufgabe nicht ‘wie von selbst’ in unabhängige Teile zerfällt. Wenn es ums reine Rechnen geht, muss man in aller Regel selbst zum Compiler greifen und sich dabei vor allem überlegen, wie man das anzugehende Problem in kleine Häppchen zerlegt, die sich parallel von mehreren Rechnern gleichzeitig bearbeiten lassen.

Umfangreiche Berechnungen, bei denen jede Teilrechnung auf den Ergebnissen vorheriger Rechenschritte aufbaut, lassen sich allerdings kaum parallelisieren. Fertige, monolithische Anwendungen, die man nicht im Quellcode erhält, profitieren nur dann von Clustern, wenn sie von vornherein für diesen Einsatz ausgelegt sind. Selbst die einzelnen Threads von Multithreaded-Programmen verteilen sich in aller Regel nicht über die verschiedenen Prozessoren im Cluster, da sie einen gemeinsamen Adressraum voraussetzen, Cluster aber eine Distributed-memory-Architektur (siehe [#kasten Glossar]) implementieren.

Je nach Art der Anwendung kann man sich allerdings mit zusätzlichen Maßnahmen behelfen. So ist es möglich, die Anfragen an einen Webserver über einen vorgeschalteten Load-Balancer auf verschiedene Rechner mit parallelem Datenbestand zu verteilen. Bei komplexeren Anwendungen wie verteilten Datenbanken ist aber ein beträchtlicher Aufwand erforderlich, um die nötige Datenkohärenz sicherzustellen; hier muss die Datenbank selbst die erforderlichen Mechanismen zum Datenabgleich mitbringen.

An dieser Stelle kommt der zweite Pferdefuß von Clustern gegenüber einem großem Supercomputer ins Spiel: die Kommunikation zwischen den Rechnern. Der ideale Job für einen Cluster sieht so aus, dass viele kleine Teilaufgaben unabhängig voneinander zu erledigen sind. Die einzelnen Rechner erhalten ein Datenpaket oder eine Client-Anfrage, verarbeiten die Daten völlig autark und liefern am Ende ihr Ergebnis ab. Ein extremes Beispiel hierfür ist das SETI@home-Projekt [2]: Jeder Besitzer eines Computers mit Internet-Anschluss kann sich ein Paket mit rund 250 KByte Radioteleskop-Daten abholen, in dem der PC dann nach Anzeichen von außerirdischen Signalen fahndet. Nach Abschluss der Auswertung schickt der Rechner zurück, was er gefunden hat.

Kommunikation
Die Kommunikation limitiert die Leistung des Clusters.

Die meisten Aufgaben bestehen jedoch nicht aus derart unabhängigen Teiljobs, bei denen die Rechenzeit ein Vielfaches der Zeit beträgt, die für die Kommunikation nötig ist. Sei es, dass die Knoten untereinander Daten austauschen müssen; sei es, dass der Master sehr große Datenmengen an jeden Knoten schicken muss, bevor der eine kurze Berechnung damit anstellt; sei es, dass die Knoten permanent auf einen gemeinsamen Datenbestand, etwa eine Datenbank, zugreifen; sei es, dass bei den Teilaufgaben die I/O-Leistung gegenüber der Rechnerei deutlich überwiegt: Sobald die eigentliche Arbeit der Knoten ins Stocken kommt, weil sie wegen eines überlasteten Netzes auf Daten warten müssen, ist die Grenze der Clusterei erreicht.

Und so scheidet sich bei der Kommunikation die Spreu vom Weizen. Ein einfaches Network of Workstations (siehe [#kasten Glossar]) eignet sich lediglich für Aufgaben, bei denen der Kommunikationsaufwand kaum ins Gewicht fällt. Bei dedizierten Clustern wie den populären Beowulf-Clustern unter Linux [3] kann man die Vernetzung von vornherein so planen, dass sie den erwarteten Anforderungen gerecht wird.

SCI-/Myrinet-Karten
SCI- oder Myrinet-Karten umgehen den TCP/IP-Stack des Betriebssystems und erreichen so deutlich kürzere Latenzzeiten.

Dabei sind verschiedene Aspekte zu berücksichtigen. Als erstes stellt sich die Frage nach der Bandbreite: Wie viele Daten müssen wie schnell übers Netz? Je nach den Anforderungen kann dann normales Ethernet (10 MBit/s, im ‘wirklichen Leben’ um 1 MByte/s) oder Fast Ethernet (100 MBit/s, real 10 MByte/s) genügen; bei höheren Anforderungen muss man zu Gigabit Ethernet (100 MByte/s) oder Speziallösungen wie SCI oder Myrinet greifen.

SCI und Myrinet gehen auch ein zweites Netzwerkproblem an, das sich in Clustern als massiver Hemmschuh erweisen kann: die Latenzzeit. Egal, wie hoch die Bandbreite des Netzes ist: Bis ein Datenpaket, von einer Anwendung auf den Weg gebracht, das Partnerprogramm auf einer anderen Maschine erreicht hat, vergeht eine halbe Ewigkeit - bei Fast Ethernet beispielsweise an die 100 Mi-krosekunden. Vor allem der zweimalige Weg durch die Netzwerkstacks der Betriebssysteme kostet Zeit.

Diese Verzögerungen fallen dann ins Gewicht, wenn die parallelen Anwendungen auf den verschiedenen Knoten in ständigem Kontakt miteinander sind - beispielsweise, weil sie permanent Statusinformationen austauschen müssen. SCI [4] und Myrinet [5] umgehen den TCP/IP-Stack des Betriebssystems und erreichen so Latenzzeiten von wenigen Mikrosekunden bei einer Bandbreite von über einem Gigabit pro Sekunde. Allerdings muss man bei SCI und Myrinet mit einem vierstelligen Betrag pro Rechner für die Vernetzung rechnen, was der Idee vom billigen Superrechner nicht eben zuträglich ist.

Ist nicht die Latenzzeit, sondern eher die Bandbreite das limitierende Element, gibt es auch bei relativ langsamen Netzen wie Fast Ethernet noch Spielräume. Ein Nachteil von Ethernet ist, dass sich alle angeschlossenen Rechner die verfügbare Bandbreite teilen müssen - ein Fast-Ethernet-Strang transportiert maximal 100 MBit/s. Wenn ein Knoten gleichzeitig mit mehreren anderen Rechnern ‘sprechen’ will, steht jedem Kommunikationskanal nur noch ein Bruchteil der Bandbreite zur Verfügung.

Abhilfe lässt sich durch mehrere Netzkarten pro Knoten schaffen: Bei drei Netzkarten kann ein Knoten über einen Switch gleichzeitig mit drei anderen Maschinen Daten mit voller Bandbreite austauschen. Durch geschicktes Routing lässt sich die Kommunikation zwischen den Knoten so optimieren, dass es zu möglichst wenig Engpässen im Netz kommt.

Doch trotz aller Tricks: In aller Regel ist es die Kommunikation, die die Skalierbarkeit eines Clusters beschränkt und dafür sorgt, dass die doppelte Anzahl an Computern die gesamte Rechenzeit nicht ganz halbiert, wie es ideal wäre. Wächst der Cluster immer weiter, kommt irgendwann der Punkt, an dem die Knoten nicht mehr rechnen können, weil sie auf das Netz warten müssen. Egal, wie viele Rechner man jetzt noch hinzufügt, die Rechenleistung des Clusters kann nicht mehr ansteigen.

Wer selbst einen Cluster aufbauen möchte, muss sich zunächst über den Einsatzzweck klar werden. Wenn es um Hochverfügbarkeit geht, wird man in der Regel eher zu einer fertigen, kommerziellen Lösung greifen. Eine einfache Fail-over-Lösung - Rechner 2 geht in Betrieb, wenn Rechner 1 ausfällt - mag man noch ‘von Hand’ basteln; echte Hochverfügbarkeit bringt jedoch eine enorme Komplexität mit sich und erfordert Hardware-seitig einen so hohen Aufwand (siehe c't 22/2000, Seite 252), dass man in aller Regel auf Komplettpakete oder auf das Know-how eines erfahrenen Systemhauses zurückgreifen wird.

Rechencluster sind schon eher eine Domäne für Bastler. Das Beowulf-Projekt [3] hat Linux für diesen Einsatzzweck populär gemacht. Erste Schlagzeilen machten Linux-Rechencluster vor knapp drei Jahren, als bekannt wurde, dass viele Effekte des Kinofilms ‘Titanic’ auf einem Linux-Cluster mit 200 Alpha-Computern berechnet wurden. Mittlerweile finden sich einige Beowulf-Cluster in der Liste der 500 schnellsten Superrechner [1]. In c't 22/2000 ab Seite 240 erfahren Sie, wie man einen solchen Linux-Cluster selbst aufbaut.

Doch es muss nicht unbedingt Linux sein. Zwar bietet dessen offene Architektur beträchtliche Vorteile, und aufgrund der vielen unterstützten Hardware-Plattformen kann man je nach Anforderung preiswerte Intel-Rechner, fließkommastarke Alpha-Prozessoren oder die ausgemusterten SPARC-Workstations unter einer einheitlichen Software-Umgebung einsetzen. Aber auch Windows NT eignet sich für Rechencluster. Der Artikel auf Seite 246 zeigt, wie normale Bürorechner unter NT nach Feierabend als Network of Workstations rechenintensive Aufgaben lösen.

Die größte Schwierigkeit beim Aufbau eines Clusters ist das Parallelisieren der eigenen Anwendung. Dabei kann es hilfreich sein, sich an folgenden vier Schritten zu orientieren:

  • Unterteilen der Gesamtaufgabe in Teiljobs, die sich parallel erledigen lassen;
  • Analyse der beim Bearbeiten dieser Teilaufgaben nötigen Kommunikation;
  • Identifikation von Teilaufgaben, die sich nicht sinnvoll trennen lassen;
  • Abbilden der resultierenden Ergebnisse auf reale Cluster-Hardware.

Hat man sein Problem in parallele Teilaufgaben zerlegt und auf einen realen Cluster umgesetzt, geht es an die konkrete Implementierung: Da sind Teilaufgaben und Daten zu verteilen, Ergebnisse einzusammeln und viele einzelne Jobs zu koordinieren. Bibliotheken wie MPI (Message Passing Interface [6]) und PVM (Parallel Virtual Machine [7]) ersparen dem Programmierer viel mühselige Arbeit, indem sie einfach zu handhabende Schnittstellen für die Kommunikation zwischen den über den Cluster verteilten Prozessen bereitstellen. Beide Bibliotheken sind für verschiedene Betriebssysteme verfügbar. Einen Einblick in das Programmieren paralleler Anwendungen mit PVM erhalten Sie in c't 22/2000 ab Seite 318.

Einen etwas anderen Ansatz verfolgt MOSIX [8]. Diese Erweiterung für den Linux-Kernel fasst die Rechner im Cluster zu einer virtuellen SMP-Maschine zusammen: Der Anwender interagiert mit einem homogenen Superrechner mit zahlreichen Prozessoren, wobei MOSIX die laufenden Prozesse so auf die Knoten verteilt, dass der Cluster insgesamt gleichmäßig ausgelastet ist. Wer eine durch viele Prozesse und womöglich mehrere gleichzeitige Nutzer stark ausgelastete Maschine durch einen Cluster ersetzen will, findet in MOSIX eine einfache Lösung. Aktuelle MOSIX-Projekte arbeiten an Dingen wie Hochverfügbarkeit oder einer effizienteren Verwaltung des Hauptspeichers.

Natürlich kann die Kommunikation zwischen den über den Cluster verteilten Prozessen nie so einfach und vor allem schnell sein wie bei einem SMP-Rechner, dessen Prozessoren über den Systembus direkt miteinander ‘sprechen’ und auf den gemeinsamen Hauptspeicher zugreifen können. Allerdings lässt sich in einem Cluster viel mehr RAM unterbringen als in einem einzelnen Rechner. Teure High-End-Server mit Intel-Prozessoren können zurzeit bis zu 32 GByte RAM, bei speziellen Architekturen sogar 128 GByte RAM adressieren - in einem großen Cluster mit mehreren hundert Knoten bringt man jedoch problemlos ein Vielfaches davon unter. Das kann bei großen Datenmengen durchaus ein schlagendes Argument für einen Rechencluster gegenüber einem einzelnen Superrechner sein: Schließlich kostet jeder Massenspeicherzugriff enorm viel Zeit.

Aber nicht nur beim Rechnen ist viel Hauptspeicher nützlich: Die Suchmaschine google.com beispielsweise setzt einen Cluster aus mehreren tausend Linux-PCs ein, um einen Volltextindex in Terabyte-Größe über mehr als eine Milliarde Webseiten im schnellen Zugriff zu haben. Allerdings sollte man nicht glauben, dass so etwas wie von selbst geht: Die Software, die ein solches System nutzen kann, findet man natürlich nicht im Software-Haus um die Ecke.

Cluster ist nicht gleich Cluster - je nachdem, was man damit tun möchte, stellen sich unterschiedliche Anforderungen und Probleme. In der jeweiligen Kombination aus Hardware, Systemsoftware und Anwendung ist jeder Cluster ein Einzelstück. Erfahrungen anderer Anwender können helfen, manche Hürde zu umschiffen und Fehlentscheidungen zu vermeiden; aber letztlich wird man immer eine eigene Lösung implementieren müssen. Cluster sind (noch?) kein Produkt von der Stange, und das Standardrezept für alle Fälle gibt es nicht.

Lohn der Cluster-Mühen ist dann aber ein System, das für einen Bruchteil des Preises die Leistung viel teurerer Rechner liefern kann. Kann, aber nicht unbedingt muss: Nicht jede Aufgabe lässt sich mit einem Cluster effizient erledigen. Selbst wenn man keine Mühen und Kosten scheut und sich bei Ausstattung wie Vernetzung der Knoten das Teuerste gerade gut genug sein lässt: Bestimmte Grenzen kann ein Cluster nicht überwinden. Wenn sich eine Aufgabe durch keine Tricks in unabhängige Teiljobs zerlegen lässt oder diese vor allen Dingen mit der Kommunikation untereinander beschäftigt sind, führt kein Weg an einem klassischen Superrechner vorbei. Zahlreiche Beispiele - von SETI@home über google.com bis zu den Beowulf-Clustern in den Top 500 - zeigen jedoch, wie breit das Anwendungsspektrum für Cluster ist. (odi)

[1] Top 500

[2] SETI@home

[3] Beowulf

[4] SCI

[5] Myrinet

[6] MPI

[7] PVM

[8] MOSIX

[#anfang Seitenanfang]


Ein Cluster ist allgemein eine Gruppe miteinander vernetzter Rechner (Knoten), die gemeinsam an einem Problem arbeiten. Von Clustern im engeren Sinn spricht man, wenn die Knoten (meist unter Kontrolle eines Masters) exklusiv für den Cluster genutzt werden und auf einem gemeinsamen Datenbestand arbeiten.

Distributed memory bezeichnet parallele Rechnerarchitekturen, bei denen jeder Prozessor exklusiv auf seinen eigenen Hauptspeicher zugreift. Bei shared memory teilen sich mehrere Prozessoren den gemeinsamen Hauptspeicher. SMP-Rechner arbeiten mit Shared-memory-Architekturen.

Die einzelnen Rechner eines Clusters bezeichnet man als Knoten. Häufig verteilt dabei ein besonderer Knoten, der Master, die Teilaufgaben auf die einzelnen Knoten und steuert so die Aktivität des ganzen Clusters. Auch die Interaktion mit dem Cluster findet in der Regel nur über den Master statt.

Load-Balancing verteilt einzelne Aufgaben wie Rechenjobs oder Client-Anfragen auf die Knoten in Abhängigkeit von ihrer Auslastung und Verfügbarkeit.

Als Network of Workstations bezeichnet man vernetzte Rechner, die - anders als die Knoten in einem typischen Cluster - auch als unabhängige Workstations genutzt werden. Das kann beispielsweise ein Firmen-LAN sein, dessen PCs ‘nach Feierabend’ gemeinsam an einer Aufgabe rechnen.

Server-Farmen bestehen aus mehreren Rechnern, die sich eine gemeinsame Aufgabe teilen; anders als bei einem typischen Cluster arbeitet dabei jeder Rechner mit seinem eigenen, lokalen Datenbestand, der nur bei Bedarf gespiegelt wird.

Mit Skalierung bezeichnet man den realen Leistungszuwachs eines Systems durch Hinzufügen von Systemkomponenten. Ein Cluster, der bei doppelter Knotenzahl nur noch halb so lange rechnet, skaliert perfekt; wenn das Hinzufügen weiterer Rechner gar keinen Leistungsgewinn bringt, skaliert das System überhaupt nicht.

SMP (Symmetrisches Multiprocessing) bezeichnet Rechner mit mehreren Prozessoren, die gleichberechtigt nebeneinander stehen und auf einen gemeinsamen Speicher (shared memory) zugreifen.

Threads (‘Fäden’) sind Teilaufgaben eines Programmes, die parallel ausgeführt werden. Auf shared-memory-Architekturen kann jeder Thread auf einem eigenen Prozessor laufen.

Kommentare

Anzeige
Anzeige